Adobe Apollo's Technology Mix: Nothing New

Last month, the first incarnation of the MAX conference under the Adobe took place, and Adobe's new Apollo runtime was the hot ticket that was previewed to developers, in preparation for the first public alpha coming up later this year and an anticipated launch of late 2007. For those who haven't heard of Apollo yet, Apollo is the code-name for Adobe's next generation runtime that basically allows developers to seamlessly combine two worlds that were mostly living in isolation of each other: HTML and Flash.

I actually was privy to work being conducted at Adobe prior to the announcement of the Macromedia acquisition, when Flash was still a technology non grata within Adobe. Times change. I was consulting on Adobe JamJar, a cool collaborative workspace project which was developed in SVG, and has since been reworked as a Flex application and is available as an alpha on Adobe Labs. While we were developing the basis for JamJar, we were also keeping tabs on the latest developments within Adobe's Advance Technology Group about mixing HTML and interactive, rich graphics together in a next-generation runtime. You can safely bet it didn't involve Flash at all. I can't go into much detail, as this information is confidential, but the concepts of Apollo were already firmly in place, but the exact technology mix was something completely different.

The new Adobe had been building a buzz around Apollo prior to MAX already, but this conference was the first time Adobe actually gave details on how developers will be able to work with Apollo. It is of course too early to make any kind of definite statement about Apollo successes or failures, but I'd like to weigh in on the two big take-away items in Chris Berchdorf's presentation on HTML integration in Apollo.

According to Chris Berchdorf, the first major take-away is that Apollo introduces a unified rendering layer for Flash and HTML content. Indeed, this is a big deal as it has always been a pain to mix and match HTML and Flash in the same Web application where Flash content would mostly be something you'd have to reference as a black box with an <object> element. There are variations to that of course, for instance the Flash plug-in can be instantiated with a transparent background which allows to have Flash content blend in nicely on top of HTML, but this has always come as an expense in terms of rendering performance. Additionally, a big issue was never, I think, resolved: rendering HTML on top of Flash content. To be fair, all of this is a shared issue of media types outside of those natively handled by a Web browser that have to integrated via a plug-in.

The scoop here is that soon, with Apollo, a single top-level rendering and compositing model will allow for all types of subtleties in how developers wish to organize HTML and Flash contents, catering for all grievances listed above. This is great news for the Flash developers, as Adobe have come to the realization that Flash cannot do it all on its own, and that certain parts are much better done in HTML and CSS. This includes, for instance, anything involving automated layout and rich text content. But, from a technological point of view, there is really nothing new here, nothing ground-breaking.

During his presentation, Chris Berchdorf showcased the new Apollo rendering capabilities by layering a Web browsing view on top of Flash-rendered contents. During the demo, the Web page was rotated, scaled, blurred and alpha-composited. This rings a bell, something we've seen demonstrated last year in an open source and publicly available codebase: Mozilla. Indeed, at XTech 2005 event (about 18 months ago), developer Robert O'Callahan showed off the then latest graphics advances in the Mozilla platform -- on which the hugely popular Firefox browser is built -- and one of this demonstration was the rendering of (X)HTML content, or entire Web pages, inside an SVG <foreignObject> element. Using this mechanism, Robert could apply all kinds of built-in SVG transformations and visual effects to the Web page: scaling, rotation, alpha compositing, blurring -- you name it. The high-level capability shown in these Apollo pre-alpha demos and those shown in Mozilla 18 months ago are the same: mixing and matching of traditional HTML and CSS content with rich graphics technology in a single rendering layer. You only have to swap Flash SWF, a proprietary binary format, with SVG, an XML-based, royalty-free language.

While this shared rendering layer for HTML and SWF is interesting, and very much a revolution in the Flash space, there is just no major achievement in the grand scheme of things here. And I think we can safely say that integrating (X)HTML and SVG together is going to be more natural to developers than putting together HTML and SWF content, given both (X)HTML and SVG are both expressed in plain text markup, literally cut from the same cloth.

Now, onto the second big take-away items from Chris's presentation: the JavaScript and ActionScript programming models are now completely bridged. Indeed, similar to the limitations in visually mixing HTML and Flash content, programmed communication between JavaScript (HTML) and ActionScript (Flash) has always been severely limited by the plug-in architecture. For instance, for an ActionScript object to be exposed in the JavaScript context, it had to be serialized to XML and then recreated as a JavaScript object. Soon, Apollo will make all of this go away, and programming across JavaScript and ActionScript will be easier than ever.

Once again, this is a big win for the Flash developers. And once again, there is nothing new here from a technological point-of-view. The API used to program HTML and CSS is the DOM. These same APIs can be used to program against any kind of XML markup, such as, for instance, SVG. In a compound XHTML and SVG document, developers can use one single set of scripting APIs, all in one context, to program both HTML and rich graphics (SVG). This is what works today in browsers such as Firefox (since version 1.5) and Opera (since version 9), and already in development builds of WebKit, the Web page rendering engine used by Apple's Safari. Both Google Maps and Windows Live Local use this functionality.

Here again, the integration between XHTML and SVG outshines the HTML and Flash mix. Even though ActionScript is based on JavaScript, the APIs you actually use to program your Flash content have nothing in common with the DOM, they are two very different things. In a compound XHTML and SVG document, you only use one set of APIs, the DOM.

Additionally, I'm wondering how Apollo will allow the kind of JavaScript programming used today, which is loosely-typed, to be used with the far more advanced incarnation used in Flash 9 which is strongly-typed and much more advanced feature-wise. Adobe have been pushing hard for Flash developers to use the latest and greatest ActionScript language-level features, but now, they have to integrate in a world that's not quite so cutting-edge yet.

Another thing that I'm wondering about is duplication of APIs. So far, Flash has lived in its own world, where it was tough for developers to leverage the host environment (HTML/JavaScript) capabilities. But the same way that Adobe have pushed for more and more application-level APIs in Flash, the browsers have been adding new APIs, and are still in the process of doing so, as work in the W3C WebAPIs Working Group and in the WHATWG shows. Which APIs will developers use for networking, drag-and-drop, cut-and-paste, etc.

My goal is not to lessen the achievements that Adobe is the process of making with Apollo, but rather to underline that the mix of HTML with real-time, rich graphics is not easiest done with two unrelated technologies as it would be with technologies built on the same grounds: HTML and SVG. Certainly, there is nothing new offered by Adobe here, and I would bet the old Adobe would have gone for something more natural. Hopefully, the old Adobe still lives, and Adobe Mars uses SVG as a complement to XHTML and CSS for its PDF-in-XML initiative.

Labels: , , , ,

0 Comments:

Post a Comment

<< Home