C'est dans l'air: développer un système d'exploitation graphique Open Source complet sur la base de:

• un système d'exploitation ouvert. e.g. Linux
• un middleware approprié (voir ci-après)
• un navigateur web en mode "kiosque" faisant office de couche graphique (DHTML) et de moteur d'exécution (Javascript) pour des petites applications faciles à développer (Widgets)
• La différence notable avec des solutions existantes est de pouvoir se passer complétement d'une stack graphique telle qu'un serveur X ou d'une machine virtuelle supplémentaire telle que Java. La zone d'affichage plein écran du navigateur forme la couche la plus basse de l'environnement graphique. Certains navigateurs, notamment Opera, peuvent ainsi fonctionner au plus près du matériel, i.e. directement branché sur le "frame buffer" et les périphériques d'entrées (clavier, souris) sans couche intermédiaire.
• La couche logicielle permettant aux applications d'accéder aux fonctionnalités de l'appareil et de cohabiter entre elles serait disponible sous la forme d'une API Javascript. Elle serait sans doute implémenté en grande partie sous la forme d'une application AJAX chargée dans le navigateur au boot. Il s'agirait ni plus ni moins d'une version embarquée d'un "portail à widgets". La différence par rapport à -par exemple- le run-time de Netvibes est que l'API Javascript est étendue à des fonctionnalités de l'appareil (stockage persistant, fonctions multimédia, BDD locale, etc.) et à des contrôles transverses de l'IHM (barre système, système de notification, icônes d'un menu, etc.).
  
• Il serait par exemple judicieux de s'appuyer sur l'offre fonctionnelle du vieux Palm OS (comme le système d'alerte) pour spécifier cet environnement en Javascript.
  
• Le produit commercial le plus proche de cette solution semble justement être le nouveau Palm webOS. Toutefois, le tout semble enrobé dans une IHM très réactive manifestement non basée sur des technos web.

Mon idée est d'aller jusqu'au bout de cette approche, et d'obtenir véritablement un "navigateur web matériel" qui ne s'appuierait sur aucune autre techno que des technos webs. J'aimerais voir apparaître une distro basée sur cette approche, prête à installer pour du matériel avec écran tactile basé sur Linux.

Le point clef de cette architecture embarquée réside dans le middleware qui relie le navigateur ave l'OS et les démons en dessous. Cette couche doit donner accès à des fonctions locales habituellement inatteignables par un navigateur. Il existe 2 approches dans le domaine.

1. écrire un plugin. Par exemple, j'ai entendu en 2008 parler d'une société qui avait écrit un plugin pour donner accès à DBUS depuis le navigateur.
2. écrire un service web local pour accéder aux couches basses par HTTP.

Selon ma logique jusqu'au-boutiste, je préfère la deuxième solution: Un accès HTTP aux couches basses. Ce choix pose ceci-dit 2 sous-problèmes.

• Je veux conserver la politique de sécurité actuelle d'un navigateur. Un widget (ie. une application) distant devra donc être d'abord être hébergé et publié par le serveur web local pour accéder à l'API HTTP locale.
• HTTP n'est pas à l'origine conçu pour remonter des évenements poussés par le serveur (les couches basses),  par exemple dans ce contexte: des évenements réseaux, matériels, multimédia... Mais la situation est en train de changer, Opera permet par exemple de s'abonner à une source d'évenements poussés par le serveur ("server-side dom event"), il s'agit simplement d'une implémentation moderne des vieilles astuces de "push HTTP" à base de connexions HTTP à longue durée de vie.

La solution technique consiste donc en:

• un serveur HTTP
• qui publie les ressources des applications/widgets installés localement
• qui offre une API HTTP d'accès aux couches logicielles embarquées sous le navigateur
• qui supporte parfaitement le Push HTTP sous sa forme la plus moderne (server-side events)
• qui se substitue à des middlewares comme D-BUS.