Google dévoile Native Client : le web en natif

…]En ce qui concerne les applications Internet riches, nous connaissons déjà les possibilités offertes par Silverlight, Flash ou Adobe AIR. C’est désormais au tour de Google de rentrer dans la danse avec son Native Client actuellement en cours de développement.

Comment profiter de la puissance du processeur de la machine pour faire tourner des applications web plus rapidement ? Google pose le problème auprès des développeurs en présentant la technologie Native Client qui est disponible pour les architectures X86 et fonctionne pour l’instant sous Mac (Intel), Linux (Ubuntu) et Windows XP avec les navigateurs Firefox, Safari, Opera et Google Chrome. A l’avenir, Google envisage de porter cette technologie sur les processeurs ARM et PowerPC.

Google s’interrroge sur les éventuels problèmes liés à la sécurité de cette technologie. En effet, alors que les applications web riches embarquent du Javascript asynchrone afin de procéder à des manipulations d’objets (ex: correction d’une photo), Native Client a pour ambition d’effectuer ces mêmes opérations directement à partir de la puissance de la machine, c’est-à-dire sans communiquer avec les serveurs du service-même.

Sur le blog officiel de Native Client, Brad Chen explique : ’ avec la possibilité de faire tourner du code natif directement sur la machine de l’utilisateur et de manière fluide, il serait possible d’effectuer ces manipulations d’images à partir du processeur. Il en résulterait une application bien plus réactive en minimisant les latences de transfert de données '.

Toujours en termes de sécurité, l’utilisateur doit aussi être assuré que seules les applications tierces autorisées fontionnent directement sur la machine. Pour ce faire, sur Linux et Mac OS X, Google utilise la technologie Strace (ptrace) qui permet de surveiller les appels système effectués par le programme. Pour Windows, cette surveillance devrait être mise en place au travers d’une liste blanche.

Du côté d’Adobe, la technologie AIR permet aussi de retrouver l’intéractivité avec un service web directement à partir de l’ordinateur et plusieurs développeurs tel que Ebay ou AOL ont développé leur propre application. Native Client se positionnera-t-il comme un véritable concurrent dans cette stratégie web2OS ou s’agit-il véritablement d’améliorer les performances pour l’utilisateur ?

Native Client n’en est qu’à ses débuts en phase bêta mais peut être avec quelques exemples de prise en main ici.

Effectivement, niveau sécurité, pour l’instant ça ne présage rien de bon : à l’instar du flash, si les calculs sont effectués côté client, ils ne sont potentiellement pas fiables (prenons exemple sur un site d’e-commerce : toutes les opérations doivent être effectuées sur le serveur et non sur le client, qui peut falsifier les données). A voir avec les propositions pour rendre ça sûr…

Sinon il y a une fonctionnalité super balèze des OS d’aujourd’hui: l’application native! On propose à l’utilisateur de télécharger le fameux logiciel de retouche photo, programmé avec un bon C++ bien optimisé. Libre à l’application de communiquer avec tous les serveurs qu’elle veut directement depuis le soft.

Certes ça ne marche pas si on veut retoucher ses photos dans un cyber-café (où on a pas le droit d’installer un programme), mais est-ce que ça mérite pour autant l’installation d’une è-nième surcouche à nos navigateur pour finalement ré-inventer les “.exe” ?

tu décris un client lourd, ça a ses intérêts mais aussi des défauts.

Et ça donnera le Web 3.0 : encore plus lourd…

On va surtout se retrouver avec des clients lourds qu’il faudra télécharger sur chaque nouvelle machine… Bref, des applications natives, mais condamnées à rester dans navigateur web, et à être multi-plateforme (ça a ses avantages comme ses inconvénients)… Bref, on en revient peu à peu à un java bridé [:kurdent]

Pourquoi ne pas faire directement des clients lourds sans installation et bridés ? (genre une machine virtuelle java spécifique, qui interdise les accès au disque)
Edité le 10/12/2008 à 16:21

Google s’interrroge !
apparemment oui, avec 3 ‘r’ c’est vraiment un casse tête ;o)

ou comment réinventer Java…

Dams333 +1.
Pour moi ils décrivent un client lourd remoté.

L’intérêt final est-il à la hauteur de l’investissement technologique et de développement ? Je n’aime pas trop le principe du PC transformé en machine à exécuter ce qu’ “on” lui envoie. Les éditeurs de logiciels contrôlent déjà bien assez ce qui se passe sur nos PC sans pour autant leur ouvrir grand la porte et les laisser y faire ce qu’ils veulent.

Moi j’aime bien avoir un PC où je peux contrôler tout ce qui s’y passe et ce genre de nouvelles technos c’est tout l’inverse. En caricaturant c’est un peu “laisse nous exécuter notre code sur ton pc, et ne te pose pas de questions”.

L’idée, c’est que, contrairement au Java, tu n’as pas besoin de compiler à la voler ton byte-code pour l’exécuter. Ici, le fonctionnement est plus proche des virtualizer (type virtualbox). Ton appli tourne directement en utilisant le processeur de la machine hôte, tu fais juste des vérifications au runtime que le code de l’appli est sur (dans un virtualizer, tu remplacerais les appels aux couches basses, ici on les interdit).

Une très bonne explication de tout çà:
http://nativeclient.googlecode.com/svn/trunk/nacl/googleclient/native_client/documentation/nacl_paper.pdf

j’ai du mal à saisir la différence entre ça et le “client lourd” ou le simple soft sans installation qu’on utilise sur son PC. :heink:

Mouais mais si on avais jusqu’à aujourd’hui suivi ta logique il faudrait installer sur son ordinateur un application youtube, flickr, facebook, myspace, igoogle, une pour chaque mini-jeux en flash à la con et tout autre site en flash/java/ajax que l’on utilise.

On croit rêver ! En gros ils parlent d’un exécutable qui communique avec un serveur distant, ce qui existe depuis une vingtaine d’années (avec divers protocoles) !

Vingt ans pour enfin se rendre compte que les technologies du web sont trop contraignantes et ne rivalisent pas avec le modèle client serveur classique ! :smiley:

Du code natif dans le navigateur ? L’ethylotest integre a gmail etait plus serieux que ca.

Euh non pas du tout, l’application est toujours sur le serveur mais le serveur envoie le code source à compiler (et non l’application) à la volée : calculs faits chez le client, résultats obtenus directement sans transferts de donnée.

Il ne pourra pas accéder à ton disque dur (sauf cookies et équivalents) et il tournera dans un navigateur… Bref, pas grand-chose de neuf…

Le java n’a pas besoin d’être compilé à la volée, il peut être précompilé, non ?

Pourtant, ça revient à ça, sauf que l’installation sera transparente (aller sur la page web suffira pour l’installer sur ton disque dur - dans le cache web) et que pour y accéder, tu n’utiliseras pas le menu démarrer mais tes favoris internet…
Edité le 10/12/2008 à 16:40

D’accord avec toi nust, mais si chacunes de ces applications étaient auto-contenues dans un fichier autonome, exécuté sans installation et mis à jour automatiquement ça aurait pu marcher.
Le setup.exe à installer c’est lourd, mais un .swf à double-cliquer ça n’est pas plus couteux que de cliquer sur l’un de ses favoris.

C’est nul.
Je ne comprend pas Google sur ce coup là.

1) ça ne tourne que sur processeurs compatible x86.
C’est un bon gros retour en arrière.
Adieu les procesesseurs autres (Sparc, ARM, PowerPC) et futurs, adieu les performances du 64 bits, adieu les instructions SSD, MMX… et tous les jeux spécialisés.
Avec en prime une version différente par variante de processeur x86 ? (avec/sans MMX, 3DNow, SSD…)
C’est pas pour rien qu’on a inventé les machines virtuelles (Java, .Net, Python…)
N’importe quoi.

2) C’est impossible à sécuriser.
Vérifier la sécurité d’un bytecode Java c’est déjà du boulot, mais du code x86, c’est du délire.
Ils sont en train de nous réinventer ActiveX, avec tous les problèmes de sécurité qui vont avec.
Et si le code s’automodifie ? ou génère du code ?
Dangereux !

3) Quid des API ?.
ptrace sous Linux ? ça veut dire que l’applet fera des appels système, par exemple pour l’affichage ?
Il faudra donc avoir des versions différentes de l’applet pour Linux, Windows, MacOSX… ?
Des versions différentes pour DirectX/OpenGL ? Pour Alsa/OSS/PulseAudio ? etc.
C’est nul.

4) Performances ?
Du code x86 sous prétexte que les performances seront meilleures ?
Mais à quel prix ? Quand votre processeur ne sera pas un x86, vous devrez émuler.
Je ne suis pas certain qu’un code x86 dans un émulateur x86 soit plus performant d’un bytecode Java ou .Net dans une machine virtuelle avec un bon JIT.

Tout cela me semble une énorme FBI (Fausse Bonne Idée).
Edité le 10/12/2008 à 16:46

L’intérêt final de ce genre de projet est de clairement se mettre en concurrence directe avec la technologie Flash. Avec une technologie comme celle-ci de nombreuses portes s’ouvrent pour la création d’applications riches sur internet. Exemple : le jeu ! En effet, le flash est affreusement lent et risque un jour de ce voir remplacer par une technologie comme celle-ci. Une question que l’on peut se poser est le taux de pénétration de cette techno sur le marché. En effet le flash est désormais incontournable, et pour le détrôner cela risque d’être difficile. A moins que Google utilise une de ses plateforme très largement utilisé pour perçer : “Youtube” qui a pour le moment un lecteur Flash ! Imaginons que demain ce lecteur soit remplacé par “Native Client” nous serions tous obligé de l’installé et alors Google aura gagné son pari…