Continued from Part 1.
I came across a post recently, which discusses the difference Flash RIAs and DHTML/AJAX RIAs. That content philosophy (preloaders, timelines, player updates) continues to drive Adobe/Macromedia Flash to legitimately suffer in the face of the Browser paradigm, despite a superior graphics runtime, (now) better script execution engine, and more consistent, cross-platform platform.
What do I mean? Well, its a bit embedded in my points from Part 1: Asynchronicity and caching are the core of the content-runtime/application-as-content business. So when I said (way back when) that the Viewpoint Media Player would be the "last version" - that's what I meant. Even the plug-in itself should consider itself no more than a cached, transient thing.
And, way back then, Macromedia (now Adobe), sort of missed the point, although the VERY last part of the last comment (by Mike Davidson) comes close: The Viewpoint Media Player was not a "Player" anymore than the Flash Player is, from a consumer perspective, nor did it possess an "update system", in any traditional sense.
The Viewpoint Media Player was (is?), fundamentally, a browser-plug-in installation system. It could download and install executable modules that extended its runtime environment (through a variety of security measures I can describe later if anyone's interested). There had been two previous versions of the plug-in (called Metastream at the time) that we had gone to GREAT lengths to get distributed, including distribution as a part of Windows98, and it sucked starting all over each time; we wanted content developers to be able to use new features immediately without disrupting the user experience - so version 3 was going to be the last.
Essentially, the core of the Viewpoint Media Player, called "Genie", is much closer to the Java/JAR-file paradigm, in that sense, than anything eelse. It could on-the-fly install modules for animation, decompression, rendering, video, basically, whatever.
And it could do so asynchronously.
If a content package lacked a Flash decoder (we had a private, reverse engineered Flash player we wrote), or a JPEG decompressor, or a Video codec, the rest of the content would play, animate, interact - whatever - until the executable module appeared (i.e. was downloaded and "installed"), and then that specific part of the content would get "handled", with nary a disruption.
In fact, I called it "Genie" because, if you had one wish, what would you wish for? In that vein, if you could install ONE thing on a user's machine, what would that thing do? (hint: Distribution is a bitch)
Yes, the Viewpoint Media Player could update itself, while it was running, in "realtime" at the request of its own currently executing content. Getting a new version (that is, updating) of a compenent was literally no different than installing a new component.
Macromedia, and others, took this to be an "update system", and with Flash Player 7 (I believe), started using a system tray to notify/download updates to the Flash Player.
But they still kind of missed the core idea - and you can still see the "philosophy delta" to HTML and the browser at work in Flash Player 9. Check out their "UI controls catalog" sample here. Note all the "loading...." screens for each component?
I'll finish in Part 3...
3 comments:
Sree, the update system of the VMP is really powerful, and I agree with the comparison to Java. In theory it should prevent a lot of "loading" screens. But in practice it isn't so much the case. It depends very much of the client/content author. Any big company that really cares about its brand requires that the content looks right immediately and will rather have a loading screen than something that looks half-baked for a few seconds.
It is the same problem with 3D streaming.
Also, it can make content authoring much harder, in particular interactions and scripting. In the end, to make content authoring easier, the developer prefers to wait for all components to be available using a loading screen.
So, yes in theory it would be possible to create content that requires few loading screens but in practice few people take fully advantage of it.
Though, you're entirely right when you say VMP doesn't really have a global version. It is extremely modular. And one big advantage is that, even if the developer uses loading screens, their display time can be dramatically reduce because only few component may need to be updated or downloaded (instead of the whole player like with flash)
Now I'd like to address the “was(is?)” statement you made about the VMP.
We are actually working on a set of new cool features for the VMP. You seem to still be proud of the technology. And I'd be delighted to talk with you about some of them if only I can successfully get some of your time (something I fail to do for the past 2 months)
I am not entirely sure what flash can do at this point. (I'll need to investigate) But I think Macromedia is making SWF much more modular in order to solve the problem you're pointing out.
At least they already do it at compilation time. (even if it is still a big mess when several developers work on the same flash code base or when you want to use SWF as Dlls). You can define classes in separated files and have the compiler automatically load the .as when you instantiate a new object of the class type (without using #include).
It feels like the next logical step would be to load .swf on demand at runtime.(if it doesn't already do it now) which would solve the problem you're pointing out. (at this point it would really work like java)
Hey niko!
I guess I was really addressing runtime performance, not author-time development difficulties (though both are valid concerns).
I agree with you about content authoring and the trials of dealing with asynchroncity - and maybe that's indeed the overlap. If you want to build good RIA content for the web, perhaps developers NEED to figure out the tools and paradigms for dealing with it - and not just punt it to the runtime.
The challenge is indeed that mixing animation, streaming, and rich presentation for a single view is hard :)
Post a Comment