La technologie Native Client de Google représente un projet un peu particulier dont le but est de pouvoir faire exécuter au navigateur du code natif. La firme de Mountain View y voit une occasion d’enrichir considérablement des applications Web, et au vu de sa stratégie générale, on comprend son intérêt. Native Client existe maintenant depuis un an environ, mais il vient de franchir une étape décisive avec la publication d’un nouveau SDK.Le code natif est celui utilisé par un système d’exploitation sans interprétation. Dans Windows par exemple, le code natif est celui écrit pour les API Win32 : le code est exécuté directement, sans aucun intermédiaire, à l’instar du C et du C++. Par opposition, des langages tels que le JavaScript et le PHP sont interprétés par un moteur tiers. Le but de Native Client est surtout de pouvoir parler aux développeurs classiques et de leur permettre d’écrire des modules en C ou C++.
Ce nouveau SDK est baptisé Artic Sea. Ceux qui ont installé la bêta de Chrome 10 l’ont déjà, sans le savoir. Dans Chrome 10, Native Client n’est cependant pas activé par défaut. Il faut ouvrir un onglet et taper dans la barre d’adresses « about:flags », puis chercher la bonne ligne.
Un grain de sel, un rien de poivre
Native Client est abrégé NaCl, un acronyme jeu de mot, puisque NaCl est le symbole du chlorure de sodium, c’est-à-dire le sel. Or, Native Client est accompagné par une infrastructure de plug-ins nommée Pepper, autrement dit poivre.
Le travail sur Native Client avance lentement, car le projet rassemble plusieurs objets, mais l’ensemble est placé sous une obligation de sécurité. Google estime désormais que cette dernière est équivalente à ce que l’on trouve pour le JavaScript actuellement, donc à travers l’utilisation d’une machine virtuelle. Ici, l’utilisation de Pepper est une avancée importante.
Pepper est une évolution d’un vieux standard créé par Netscape : NPAPI. Son utilité est inscrite dans son appellation : Netscape Plugin Application Programming Interface, autrement dit une infrastructure pour les plug-ins. On la trouve dans de très nombreux plug-ins actuels, mais Google n’était pas satisfaite des limitations de cette technologie. Pepper réunit plusieurs interfaces qui vont pouvoir permettre l’utilisation du matériel de l’ordinateur, notamment des cartes graphique et son, bien que des proportions limitées.
Garder tout le code dans des zones isolées
L’aspect sécurité intervient d’ailleurs à travers Pepper. Débutée comme une simple évolution de NPAPI pour s’affranchir de certaines limites, l’infrastructure a évolué de manière propre, mais avec une différence de taille : là où NPAPI permet de charger des plug-ins en dehors du navigateur, Pepper le fait « dans » ce dernier, permettant ainsi au passage d’appliquer toutes les sécurités inhérentes à Chrome. Dont, bien entendu, l’isolation des processus dans des sandbox, ces espaces mémoire fermés à tout impact sur le reste du système (la lecture reste autorisée).
Google ne considère pas Native Client comme une technologie réellement prête à l’emploi par tous les développeurs, et ces derniers ne sont qu’invités à se familiariser avec la technologie. Dans les prochains mois, d’autres API seront ajoutées à Native Client :
- Graphismes 3D
- Stockage local
- WebSockets
- Partage P2P
On comprend évidemment pourquoi cette technologie est aussi importante pour Google : puisque la firme s’oriente toujours plus vers le cloud computing et donc les services distants, NaCl pourrait permettre l’exploitation des ressources locales via du code natif. Bien que la question de la sécurité soit cruciale, Google est confiante sur la question, en rappelant d’ailleurs qu’il ne s’agit que d’un travail en cours.
Ceux qui souhaitent se renseigner davantage sur Native Client pourront se rendre sur la page du projet. Il faut noter qu'il s'agit d'un projet Open Source et que Google n'a aucun intérêt à limiter cette technologie au seul Chrome.
