| french | english |
 |
|
| Créer un compte | |
| 30-08-08 / 21:59 : QuickTimeX : le RDA par Apple ? (cjed) |
| Les informations concernant QuickTimeX commencent à se répandre. Ce framework énorme (développé et enrichi depuis 1991, et qui fait de plus en plus usine à gaz) est difficile à maintenir et ne facilite pas la traque des éventuelles failles de sécurité. Apple a tout d'abord commencé en 2003 à simplement wrapper les APIs QuickTime en C par des objets Cocoa (l'Objective-C peut appeler du C et du C++, mais dans ce cas on ne bénéficie pas des avantages du runtime Objective-C : vrai système de délégation de message, typage dynamique, etc.), puis a progressivement réécrit le contenu de ces classes en tirant partie de l'Objective-C et du framework Cocoa (nouveau framework QTKit). Ce travail devrait être terminé pour Snow Leopard. Deuxièmement Apple doit contrer le Flex d'Adobe et Silverlight de Microsoft pour conserver une place dans le domaine du client web riche. Pour ce faire on peut supposer que QuickTimeX proposera un format de code interprétable standardisé (le même quelle que soit la plateforme), qui sera interprété par le container QuickTime (sorte de machine virtuelle ou d'interpréteur, de la même manière que Flash avec l'ActionScript, Director/Shockwave avec le Lingo, ou encore ScumVM avec le langage utilisé pour les jeux LucasArts !) QuickTime possède déjà les APIs de gestion des médias (audio/vidéo), terrain sur lequel se joue la compétition entre Flex/Flash, Silverlight et GWT. Il ne reste plus qu'à lui ajouter la gestion d'une interface utilisateur classique (vues, widgets, etc.) Cela pourrait être fait tout en conservant la partie programmation en Cocoa côté MacOSX (et seulement), ce code serait ensuite transformé en code interprétable par le container QuickTimeX. Ainsi on disposerait des mêmes applications sur Windows, sans avoir à y déployer ni les outils de développement, ni surtout Cocoa. Plus besoin de Yellow Box donc, QuickTimeX EST la YellowBox ! On se rapprocherait quelque part du fonctionnement de Cappuccino (programmation en Objective-J, syntaxe identique à l'Objective-C, puis conversion dynamique au runtime en javascript standard). Le javascript final exécuté avec la solution Cappuccino étant par nature limité au niveau de la gestion des medias (on peut faire du dessin 2D en javascript, donc gérer des instructions d'affichage en provenance de Quartz et CoreAnimation, mais on ne peut pas gérer de la vidéo), Apple utilisera probablement un nouveau format de code interprétable par le container, dont elle gardera le secret et le contrôle pour éviter toute concurrence. A la limite, comme avec les solutions concurrentes, on ne peut plus vraiment parler de client riche web, puisque le protocole HTTP et le HTML ne sont plus utilisés pour gérer les interactions avec l'interface utilisateur (HTTP sert uniquement de transport pour l'appel des webservices métier déployés sur les serveurs J2EE). Avec la vitesse des connexions actuelles on peut même envisager le retour des applets ! Après tout personne ne se plaint des quelques secondes d'attente lors du chargement du javascript d'une application GWT ! Et pourquoi pas remplacer le navigateur par un autre container, par exemple le container QuickTimeX qui ajouterait le support des connexions HTTP pour les communications avec les webservices ! C'est ce qu'on appelle les RDA (Rich Desktop Application, voir également ici et là). Adobe a présenté début 2008 sa solution AIR (anciennement projet Appolo), un container qui utilise Flex. MAJ : en réalité Cappuccino permet de manipuler des vidéos QuickTime, puisque l'application de démo 280 slides propose cette fonctionnalité dans les diaporamas. En effet on peut manipuler des séquences QuickTime depuis du javascript comme je le rapportais dans cet article (explications ici et là. La possibilité inverse - appel de javascript depuis QuickTime - était possible jusqu'à la version 7.1.5, et a été supprimée ensuite pour des raisons de sécurité). Le bridge javascript --> QuickTime est cependant limité au contrôle d'une séquence (lecture, avance dans le fim, choix des pistes et des langues). Une exécution de l'application client riche dans le container QuickTimeX permettrait une manipulation plus poussée des fonctions multimédia. |
| Commentaires |
| Poster un commentaire |