S'identifier / Créer un compte
  • Actualités
  • Dossiers
  • Tests
  • Commentaires
  • INpactiens
Publicité

Google Native Client, pour exécuter du code natif dans Chrome

Le futur des applications Web ?

google native clientLa 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.

google native client

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
Google travaille également sur les Dynamic Shared Objects, qui permettront à terme d’atteindre le niveau voulu de stabilité pour l’Application Binary Interface. Tant que celle-ci n’est pas prête, Native Client ne sera pas activé par défaut dans Chrome.

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.
Source : Google
Vincent Hermann

Rédacteur/journaliste spécialisé dans le logiciel et en particulier les systèmes d'exploitation. Ne se déplace jamais sans son épée.

Publiée le 21/02/2011 à 11:03

Soutenez l'indépendance de Next INpact en devenant Premium

  • Tout le contenu de Next INpact sans pub
  • Et bien plus encore...

Il y a 120 commentaires

Avatar de Krogoth INpactien
Krogoth Le lundi 21 février 2011 à 11:09:13
Inscrit le mardi 10 mai 05 - 2587 commentaires
C'etait pas le but des applets JAVA?
Avatar de Vincent_H Equipe
Vincent_H Le lundi 21 février 2011 à 11:11:19
Inscrit le jeudi 30 janvier 03 - 15418 commentaires
C'etait pas le but des applets JAVA?


La news te parle de code natif et tu réponds Java. Wrong way
Avatar de Crysalide INpactien
Crysalide Le lundi 21 février 2011 à 11:14:42
Inscrit le mardi 24 mars 09 - 5368 commentaires
Le projet étant open source (merci GG), ceci pourrait être une des voies que pourrait emprunter Mozilla pour se lancer dans les RIA, non ?

Car faut avouer que Firefox risque d'être bloqué à un "simple" navigateur dans les années à venir, alors qu'IE ou Chrome implémenteront le services web (Office, GG Docs, cloud et cie) proposés par leur éditeur respectif.
Avatar de Spaz001 INpactien
Spaz001 Le lundi 21 février 2011 à 11:14:48
Inscrit le mardi 31 octobre 06 - 34 commentaires
[quote]le code est exécuté directement, sans aucun intermédiaire, à l’instar du C et du C++. Par opposition, des langages tels que [...] le C# sont interprétés par un moteur tiers[/quote]

C# ? Interprété ?
Avatar de brice.wernet INpactien
brice.wernet Le lundi 21 février 2011 à 11:17:14
Inscrit le mardi 18 mars 03 - 1552 commentaires

La news te parle de code natif et tu réponds Java. Wrong way

Natif x86 au lieu de code pour une pseudo machine au moment ou même microsfot annonce un "Windows 8" compatible ARM, ça me semble wrong way aussi.
Une VM permettant de générer du code efficace:
- d'une part en permettant de gérer des instructions "modernes" (SIMD qui seraient réllement mappées sur des instructions natives SIMD)
- d'autre part en ayant une infrastructure adaptée aux multi-coeurs
- enfin en permettant de "décorer" le bytecode de façon à recompiler plus efficacement en fontion de l'archi hôte

Ca, ça serait pour moi le "good way"
Avatar de wagaf INpactien
wagaf Le lundi 21 février 2011 à 11:17:20
Inscrit le lundi 15 mai 06 - 1771 commentaires
Le projet étant open source (merci GG), ceci pourrait être une des voies que pourrait emprunter Mozilla pour se lancer dans les RIA, non ?

Car faut avouer que Firefox risque d'être bloqué à un "simple" navigateur dans les années à venir, alors qu'IE ou Chrome implémenteront le services web (Office, GG Docs, cloud et cie) proposés par leur éditeur respectif.


Les RIA n'ont aucune raison de ne pas être compatible avec Firefox. D'ailleurs Google Docs est parfaitement compatible avec Firefox.

Les RIA n'ont en fait pas grand chose a voir avec l’exécution de code natif.
Avatar de zglurb INpactien
zglurb Le lundi 21 février 2011 à 11:20:02
Inscrit le lundi 7 janvier 08 - 649 commentaires
En gros Google veut refaire le système de plugins pour navigateurs qui devient viellot. C'est bien... mais ça serait pas mieux de faire ça en concertation avec les autres navigateurs ? Histoire de faire un truc standard ?


La news te parle de code natif et tu réponds Java. Wrong way


Bah il a pas tort je crois ? La JVM doit se greffer aux navigateurs avec NPAPI. Enfin je crois

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.


En tout cas ça rigole bien chez Google
Avatar de wagaf INpactien
wagaf Le lundi 21 février 2011 à 11:20:46
Inscrit le lundi 15 mai 06 - 1771 commentaires
Natif x86 au lieu de code pour une pseudo machine au moment ou même microsfot annonce un "Windows 8" compatible ARM, ça me semble wrong way aussi.
Une VM permettant de générer du code efficace:
- d'une part en permettant de gérer des instructions "modernes" (SIMD qui seraient réllement mappées sur des instructions natives SIMD)
- d'autre part en ayant une infrastructure adaptée aux multi-coeurs
- enfin en permettant de "décorer" le bytecode de façon à recompiler plus efficacement en fontion de l'archi hôte

Ca, ça serait pour moi le "good way"

Je ne pense pas que l'objectif soit de faire des sites utilisant cette API, plutôt des extensions permettant de tirer partie de certaines fonctions natives (comme le font les plugin Google Earth et Google Talk par exemple).

Plutôt dans l'optique de ChromeOS, et de l'utilisation du navigateur comme seule application installée.


Edité par wagaf-d le lundi 21 février 2011 à 11:22
Avatar de 127.0.0.1 INpactien
127.0.0.1 Le lundi 21 février 2011 à 11:23:28
Inscrit le mercredi 29 avril 09 - 13213 commentaires

NaCl : L' ActiveX vu par Google.

L'avenir du Web, c'est le [strike]standard HTML[/strike] plugin.
Avatar de Vincent_H Equipe
Vincent_H Le lundi 21 février 2011 à 11:25:30
Inscrit le jeudi 30 janvier 03 - 15418 commentaires

C# ? Interprété ?


Non effectivement pas, je ne sais pas comment je me suis retrouvé à écrire ça alors que je pensais au PHP à la base. Toutes mes confuses
;