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...