|
30-08-08 / 21:59 : QuickTimeX : Apple's RDA ? (cjed) | Informations about QuickTimeX are starting to arise. This huge framework (developped and enhanced since 1990) is difficult to maintain and does complicate identifying of potential security flaws. Apple started around 2003 wrapping QuickTime C APIs by Cocoa objects (Objective-C can make call to C and/or C++ code), however these were only true basic wrappers, so they didn’t benefit from the Objective-C runtime (true messaging system with delegation, dynamic typing, etc.). Later they introduced QTKit, a new Cocoa framework (previous classes contents were being progressively rewritten in Objective-C, using Foundation classes and other Cocoa classes from core frameworks). This transition should be completed as Snow Leopard ships.
Secondly Apple has to respond to Adobe's Flex and Microsoft's Silverlight to gain a place in the rich web client market. So we can suppose QuickTimeX would bring a new standardized interpreted code format (the same on any platform), that will be interpreted by the QuickTime container (in the same manner as Flash's ActionScript, Director/Shockwave's Lingo, or even LucasArts games interpreter language !)
QuickTime still includes required APIs to manage medias (audio/video), that is an area were the competition is strong between Flex/Flash, Silverlight and GWT. There is still to add the management of standard user interface elements (views, widgets, etc.) This could be done while keeping the programming side on MacOSX (only), this code would then be converted to the execution code format managed (interpreted) by the QuickTimeX container. In such a scenario the same code base (written in Cocoa) could be deployed in any platform, without having to expose developper tools to Windows, nor (main point) having to deploy Cocoa in Windows. Finally there isn't nor more need for a Yellow Box, QuickTimeX IS the YellowBox !
Then QuickTimeX platform would be close to the Cappuccino idea (Objective-J programming - identical syntaxe to Objective-C -, and then dynamic conversion - at runtime - to javascript). The ending javascript executed with the Cappuccino solution is however limited in medias areas (2D drawing is possible, so interpreting of Quartz and CoreAnimation drawing instructions is managed by Cappuccino, but the javascript can't handle video), Apple will probably use a brand new interpreted format for the container, that will be keeped close to avoid competition.
At the extent, as with competing solutions, we cannot call it anymore a web rich client platform, as the HTTP protocol and HTML language aren't used anymore to manage interaction with the user interface (HTTP then only provides the transport layer for the business webservices calls, that are deployed on regular J2EE application servers). With actuall internet connections speed, even the applets could be back ! Nobody is complaining about the few seconds of javascript loading when lauching a GWT application ! And why not fully replace the browser by the QuickTimeX container, if it gains support for HTTP communications (allowing to call the webservices) !
That is what is called RDA (Rich Desktop Application, see also here and there). Adobe presented early 2008 its RDA solution, AIR (previously Appolo project), a container that uses Flex.
UPDATE : in fact Cappuccino can still handle QuickTime videos, as the 280 slides demo application provides this feature for slideshows. We can gain control of QuickTime sequences from javascript as I reported in this article (see explanations here and there. The opposite way was allowed - javascript call from a QuickTime sequence - but that feature has been removed in QuickTime versions following 7.1.5, due to security concerns). The javascript --> QuickTime bridge is however limited to basic sequence objects handling (play, forward, selecting tracks and languages). An execution of the rich client application in the QuickTimeX container would allow fare more further access to multimedias functions. | | Comments | Write a comment | |
|