Browser 2.0 : un nouveau browser pour des interactions plus riches

Lorsque l'on cherche à classifier les applications et que l'on s'intéresse aux technologies d'interface homme-machine, nous avons désormais pris l'habitude de distinguer deux filières principales : la filière RIA, " Rich Internet Applications " et la filière RDA, " Rich Desktop Applications ". Est-il possible de tirer partie des avantages respectifs de ces deux technologies? Un petit délire sur une solution mixte...

Dans le premier cas (RIA), le navigateur web est utilisé comme environnement d'exécution des applications, c'est-à-dire comme conteneur pour le code développé en HTML, Javascript et autre CSS. Grâce à des efforts importants de communautés open source et d'éditeur, le niveau d'interaction (de " richesse ") proposé par ce type d'applications est en augmentation constante, avec des efforts importants pour se rapprocher du niveau d'ergonomie des applications natives. On peut citer à titre d'exemple le framework ajax " page bus " de Tibco qui a vocation à proposer une approche événementielle pour les développements Javascript.

Dans le second cas (RDA), le navigateur web est utilisé comme moyen d'accès à l'application : un lien sur une page permet de lancer un plugin côté client qui, via le browser, récupère les composants de l'application. Une fois téléchargée, l'application s'exécute de manière autonome, le browser n'étant plus utilisé. Comme exemple concret, il est possible de citer la technologie Java Web Start de Sun qui joue le rôle de lanceur et d'updateur depuis le serveur (si une nouvelle version de l'application est disponible). Dans le monde Eclipse, le browser est même totalement contourné : c'est la plate-forme Eclipse qui se charge de récupérer les nouvelles versions de l'application et qui agit comme un " browser d'applications RDA ". Il y a ici peu de limites dans le niveau d'ergonomie atteignable, sans les limites imposées par le browser (sécurité, accès au file system, accès à des périphériques...).

Il peut être intéressant de réfléchir aux moyens de marier le meilleur de ces deux mondes. Ainsi, on peut imaginer un browser web capable d'offrir une vraie " infrastructure " desktop, contenant des applications web qui pourraient désormais interagir fortement avec ce browser, en le modifiant (par exemple par ajout de fenêtre, d'entrées de menus du browser...) ou en communiquant avec lui (par exemple par déclenchement d'un événement qui serait propagé à l'OS ou à une autre application également hébergée dans le browser). Le browser deviendrait un pont entre l'application web et les fonctions offertes par l'OS, puis dans un second temps avec toutes les applications du poste ; il serait capable de gérer le multi-fenêtrage associé à plusieurs applications ouvertes en parallèle, avec toutes les fonctionnalités associées (sauvegarde de l'état du browser et des préférences utilisateur, habilitations...).

Que gagnerait-on avec ce browser hybride ? Il serait possible de lever des limites des deux filières classiques puisque l'on aurait une infrastructure totalement ouverte vers le poste local, qui permettrait aussi une ouverture sur le web. Il serait possible de proposer le même niveau d'interactivité que les applications locales sans avoir besoin de réinventer toute une ergonomie dans le cadre contraint du browser habituel. D'un point de vue performances et fluidité des applications, un gain substantiel pourrait être envisagé puisque le browser permettrait d'utiliser des composants performants de l'OS, dont l'imitation en RIA donne parfois lieu à des implémentations poussives.

Fermez les yeux deux secondes et imaginez un peu :

• L'utilisateur lance son browser " new generation " et saisit l'URL d'une application

• Lors de son lancement, l'application " déclare " au browser qu'elle a besoin des 3 onglets supplémentaires (positionnés en haut à gauche pour 2 d'entre eux et en bas pour le dernier afin de constituer une barre de messages pour l'utilisateur) ainsi que d'un composant " browser " chargé de piloter MS Word

• Durant l'exécution, l'application va pousser des informations dans chacun des 3 onglets, lancer MS Word pour lui injecter un document type rempli de données issues de l'application, que l'utilisateur modifie (dans MS Word !) et re-soumet à l'application

• Parce qu'il a besoin de faire une recherche sur le web, l'utilisateur lance Google : il lui suffit de lancer la page web dans un onglet. Pour une application web classique, la plate-forme est un simple browser 1.0 et il héberge l'application de manière transparente.

Dans une utilisation " totale ", le browser deviendrait une plate-forme RDA capable d'héberger des applications web. Dans une utilisation " basique ", on aurait un simple browser web. L'avantage est... qu'il est possible de faire les deux au sein d'une même plate-forme, selon le type d'application ! Par ailleurs, l'accès aux ressources et aux composants IHM natifs de l'OS serait possible via ce browser.

Alors, vous êtes partants ? Comment pourrait-on implémenter avec les technologies d'aujourd'hui cette nouvelle filière de browser ?

Première solution : en s'appuyant sur un browser qui offre déjà un modèle de framework de programmation d'IHM, à savoir FireFox avec son framework XUL. Notre application web pourrait être développée de manière " classique " (Javascript + HTML + CSS + tiers serveur en langage de votre choix) et envoyer des instructions XUL au browser (avec un mécanisme à trouver J) pour que celui-ci se déforme et ajoute des morceaux d'IHM " réellement riches " (= en technologie de l'OS).

Deuxième solution : en s'appuyant sur une solution RDA capable de piloter un browser, à savoir Eclipse RCP par exemple. Dans ce modèle, l'application web classique remonte des instructions à la plate-forme qui se déforme également ; ce mécanisme est ici possible du fait de la capacité d'Eclipse RCP à intégrer (via un composant ActiveX) un browser web et à communiquer avec lui via ce " pont " ActiveX. Autre avantage : il est également possible de déployer dans ce browser de vraies applications RDA, développées dans la technologie Eclipse.

De nombreux enjeux restent à adresser pour parvenir à développer ce type d'applications :

• Comment développer une application " cross browser " ? Pour l'être vraiment, elles n'exploiteraient pas les nouvelles fonctionnalités offertes par ce browser de nouvelle génération et seraient alors de " simples applications internet riches "...

• Faut-il introduire une nouvelle technologie, c'est-à-dire encore un autre browser en plus du nombre déjà important ? Comment capitaliser sur le très large parc installé d'IE?

• Quel langage de programmation pour l'API du browser ? Quel protocole derrière cette API, c'est-à-dire quelle structure de message et d'échange de message entre les applications et le browser hybride ?

• Comment gérer les problématiques de sécurité de ce nouveau browser qui permet à une application web d'interagir fortement avec l'OS ?

• Enfin, la complexité introduite en vaut-elle la chandelle ? On peut imaginer que développer une telle application pour un développeur peu expérimenté risque d'être assez complexe, vu le mélange de technologies.

... mais on peut toujours rêver :o). Il y a quelques années, on avait des écrans noirs et verts en 32/70.