Discussion :

[Katleen Erna]

Google offre un SDk permettant de créer des web apps natives en C et C++ dans son navigateur Chrome

Google vient de sortir une présentation du SDK de Native Client, sa technologie open source qui permet à des codes natifs en C et C++ de s'exécuter dans un navigateur. Ceci permettra d'utiliser des applications plus avancées sur le web, et qui pourront tourner dans Google Chrome.

Les capacités des applications web sont étendues au delà des limites imposées par l'utilisation de JavaScript.

Un aperçu vidéo du SDK vient d'être publié, il montre les bases de son utilisation : comment se lancer dans l'écriture d'une application en quelques minutes seulement.

Google offre donc un compiler C et C++ basé sur GCC, ainsi que des extraits de code source pour aider les développeurs à créer des applications conforme au code natif.

Mais alors que JavaScript est disponible pour différents navigateurs, Native Client se limite à celui de son concepteur : Chrome.

Ce qui ne satisfait pas tout le monde... Sur le blog officiel annonçant l'outil, un internaute anonyme écrit "Native Client est un grand bond en arrière pour moi", avant de continuer : "Qui voudrait utiliser Native Client quand ça empêchera ses applications de tourner sur plein de plateformes, comme les anciens Macs, les smartphones, les tablettes, les smartbooks équipés de processeurs ARM, etc... ?"

Google répond à cela que la portabilité sera sa priorité, et que la firme se concentre sur l'élaboration d'un système qui sera neutre en terme de plateformes.

Les développeurs de la compagnie travaillent également sur un autre projet, en parallèle : le V8 JavaScript Engine qui aide l'accélération des applications web.

Pour autant, les deux ne sont pas en compétition, car Google estime "qu'il y a certaines parties des applications que les gens veulent écrire en JavaScript, et d'autres qu'ils veulent écrire dans d'autres langages".

Source : La vidéo d'aperçu de Native Client :
[ame="http://www.youtube.com/watch?v=nP8Mo0jGQDk"]YouTube- Introducing the Native Client SDK[/ame]

Pensez-vous que Native Client soit "un grand bond en arrière" ?

Souhaitez-vous un élargissement de Native Client à d'autres plate-formes ?

Quels sont, selon vous, les avantages à développer des applications pour Chrome ?

[metagoto]

J'ai trouvé mon jouet pour ce (court) week end

[stardeath]

Pensez-vous que Native Client soit "un grand bond en arrière" ?

ne pouvant pas blairer ni html, ni javascript, ni java (ça fait beaucoup) je dirai juste enfin ><
après le fait que blabla ça tourne pas sur d'autres plateformes, va provient pas de c/c++, si il y a ce qu'il faut dans le navigateur, ça devrait pas poser de problème, vu que javascript tourne déjà.

mon véritable problème c'est javascript, que je considère comme une infâme ignominie.

[supersnail]

Whaou!

Google vient de réinventer l'ActiveX

Bref, faut juste espérer que le Native Client ne soit pas une daube infâme comme les ActiveX , avec tous les problèmes de sécurité que ce dernier a engendré...

Bref, si Google Chrome se met à commettre les mêmes erreurs que Firefox, je crois que je vais revenir sous Firefox (ou passer définitivement sur Midori)

[Mat.M]

Google vient de réinventer l'ActiveX

Bref, faut juste espérer que le Native Client ne soit pas une daube infâme comme les ActiveX , avec tous les problèmes de sécurité que ce dernier a engendré...

grosse daube c'est vite dit : si c'est bien conçu la technologie Active X peut-être intéressante.
Le problème ce sont les personnes mal intentionnées qui veulent utiliser cela pour envoyer des virus ou faire des spywares c'est un peu vrai

[Mat.M]

Google vient de sortir une présentation du SDK de Native Client, sa technologie open source qui permet à des codes natifs en C et C++ de s'exécuter dans un navigateur. Ceci permettra d'utiliser des applications plus avancées sur le web, et qui pourront tourner dans Google Chrome.

Cela pourrait devenir intéressant pour Android
Ceci dit cela peut ouvrir des perspectives intéressantes si on peut compiler en code natif : par exemple de la 3d affichée à partir d'un navigateur , des jeux performants...
mais j'arrête-là on va me dire qu'on peut faire la même chose en Java

Google offre donc un compiler C et C++ basé sur GCC, ainsi que des extraits de code source pour aider les développeurs à créer des applications conforme au code natif.

Pensez-vous que Native Client soit "un grand bond en arrière" ?

oui le C++ c'est dépassé , Java et .NET c'est mieuxxe

[exodev]

Qu'en est-il de la sécurité pour empêcher le lancement de programmes malicieux avec une telle solution?

[ghost10]

bon rigolez pas mais c'est quoi un code natif?? comme ça je comprendrai mieux

[vadreb]

Qui voudrait utiliser Native Client quand ça empêchera ses applications de tourner sur plein de plateformes, comme les anciens Macs, les smartphones, les tablettes, les smartbooks équipés de processeurs ARM, etc... ?

Ça pourrait être intéressant pour un intranet d'entreprise.
On se fou pas mal des autres plateformes quand on s'en sert seulement pour exécuter des applications internes...

[gb_68]

Whaou!

Google vient de réinventer l'ActiveX

Bref, faut juste espérer que le Native Client ne soit pas une daube infâme comme les ActiveX , avec tous les problèmes de sécurité que ce dernier a engendré...

Au contraire. J'avais plutôt peur que le projet n'aboutisse jamais, car ce que tente de proposer NaCl, c'est (enfin ?!) une sandbox pour applications natives, et ce pour tous les OS.

[benwit]

ce que tente de proposer NaCl, c'est (enfin ?!) une sandbox pour applications natives, et ce pour tous les OS.

Tout a fait, si le problème de sécurité est géré et si on a une "sandbox" universelle, ça peut être pas mal.
Ce qui pourrait être sympa, c'est que GWT compile directement en code natif aussi !

[Invité]

Ce qui ne satisfait pas tout le monde... Sur le blog officiel annonçant l'outil, un internaute anonyme écrit "Native Client est un grand bond en arrière pour moi", avant de continuer : "Qui voudrait utiliser Native Client quand ça empêchera ses applications de tourner sur plein de plateformes, comme les anciens Macs, les smartphones, les tablettes, les smartbooks équipés de processeurs ARM, etc... ?"

En fait Google est plus malin que Apple au lieu d'attaquer de front le flash d'Adobe, ils se contentent de proposer une solution pour éradiquer le flash : beaucoup plus rapide, avantage pour la longévité des smartphones et pas de problèmes anti-trust.

bon rigolez pas, mais c'est quoi un code natif?? comme ça je comprendrai mieux

L'assembleur, le c et le c++ pour les plus courants, les fichiers textes contenant le code sont compilés en code machine propre à chaque processeur et OS (un programme compilé pour Linux ne fonctionnera pas sous Windows et inversement).
C'est le plus rapide et pas portable.
Le javascript par exemple n'est pas natif c'est du script (!!!) c'est le navigateur qui exécute le script ligne par ligne à chaque exécution (le navigateur est écrit en natif).
Autre langage de script php, bash, perl par exemple.
En fait, il y a une machine virtuelle écrite en code natif qui manage les scripts en compilant certaines parties... donc c'est un peu plus compliqué que ça.

[Invité]

Multi-plateformes, ça veut dire que ça marchera sous Linux.chrome ?
Je trouve intéressant le principe de gcc, je ne trouve pas pénalisant l'obligation d'utiliser chrome puisqu’il est installé sur tous mes pc's ainsi que FF et IE.

L'API reste une question clef : va-t-on gérer des « form » html ou des « form » "maison" comme activeX qui était- il est vrai - assez similaire.

Pour l'interopérabilité, elle ne me semble ni pire ni meilleure que les plugs-in et en gros, elle ne peut que s'améliorer si html 5.1 venait à standardiser les meilleures idées. Sincèrement, j'ai toujours respecté l'intelligence de Google, il reste à découvrir si l'api a vocation à devenir une norme ou si, au contraire, elle consiste à bloquer toute concurrence (comme font presque tous les éditeurs du reste)

[Invité]

Est-ce moi ou ces deux affirmations sont complètement contradictoires ?

[...]
Mais alors que JavaScript est disponible pour différents navigateurs, Native Client se limite à celui de son concepteur : Chrome.
[...]
..."Qui voudrait utiliser Native Client quand ça empêchera ses applications de tourner sur plein de plateformes, comme les anciens Macs, les smartphones, les tablettes, les smartbooks équipés de processeurs ARM, etc... ?"

Google répond à cela que la portabilité sera sa priorité, et que la firme se concentre sur l'élaboration d'un système qui sera neutre en terme de plateformes.

C'est ptetre moi car "plateforme" est sans doute à prendre au sens de "processeur cible" ou encore "plateforme matérielle", question ôô combien importante pour c/c++ et complètement inutile pour les technos web (hors plugin)

Je pense que cette confusion complique la compréhension de cette news.
En effet, on oublie souvent que les appli web sont certes peu performantes mais très multiplateformes, on a pris des habitudes de riche en s'imaginant écrire du code à la fois performant et capable de tourner sur n'importe quoi.

En s'appuyant sur gcc qui a été porté sur tous les systèmes, google n'a plus qu'à installer des constantes qui seront testées dans le code à la différence des #ifdef qui sont testées par le compilateur une fois pour toutes.

Bref, à part l'empilement des architectures qui va donner des trucs du style

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

char * mastring="<script> var mastring = \"\<a href=\\\"monlien.php\\\"\>;</script>";

on aboutit bien à un client en code natif, il faut juste faire attention à différencier plateforme OS, plateforme Navigateur et plateforme matérielle , sinon on s'y pert un peu

Me trompè-je ? (sos help la communauté)

[Invité]

Au contraire. J'avais plutôt peur que le projet n'aboutisse jamais, car ce que tente de proposer NaCl, c'est (enfin ?!) une sandbox pour applications natives, et ce pour tous les OS.

Salut gb 68,

Peux-tu nous en dire plus sur NaCl ?

Comment un ____.exe peut-il contenir le même code C compilé pour plusieurs processeurs cible dans le même fichier ???

Personnellement, je n'ai jamais entendu parler d'un truc pareil

Fais-je fausse route ?

[supersnail]

Bonjour,

On a parlé de code natif... Mais pourquoi ce serait forcément un exécutable?

Ça peut très bien être un binaire plat, voire même un format d'exécutables "made in Google" (différents du format PE ou ELF), qui n'est compatible qu'avec son navigateur (en gros,impossible de lancer le binaire sans passer par le navigateur)...

En gros, le navigateur serait "l'OS" de ces binaires, et toutes les transactions (ouvrir/fermer un fichier, etc...) passeraient par le navigateur, qui laisserait passer (ou non) les demandes de création de fichiers, etc...

[JeitEmgie]

Bonjour,

On a parlé de code natif... Mais pourquoi ce serait forcément un exécutable?

Ça peut très bien être un binaire plat, voire même un format d'exécutables "made in Google" (différents du format PE ou ELF), qui n'est compatible qu'avec son navigateur (en gros,impossible de lancer le binaire sans passer par le navigateur)...

En gros, le navigateur serait "l'OS" de ces binaires, et toutes les transactions (ouvrir/fermer un fichier, etc...) passeraient par le navigateur, qui laisserait passer (ou non) les demandes de création de fichiers, etc...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
hello_world.nexe: ELF 32-bit LSB executable, Intel 80386, version 1, statically linked, not stripped

[JeitEmgie]

Salut gb 68,

Peux tu nous en dire plus sur NaCl ?

Comment un ____.exe peut-il contenir le même code C compilé pour plusieurs processeurs cible dans le même fichier ???

Personnellement, je n'ai jamais entendu parler d'un truc pareil

Fais-je fausse route ?

ce qu'on appelle souvent des "FAT binaries"…

vous mettez ce que vous voulez dans un fichier…
simplement il faudra un loader adapté à ce format de fichier…

mais apparemment la solution de Google est de mettre les binaires dans une structure de directory…

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
  <script type="text/javascript">
    contentDiv = document.getElementById('nacl_helloworld_content');
    if (window.location.hash == '#develop') {
      // Load the develop version of the module.
      contentDiv.innerHTML = '<embed name="nacl_module" '
                             + 'id="hello_world" '
                             + 'width=0 height=0 '
                             + 'type="pepper-application/hello_world" />';
      moduleDidLoad();
    } else {
      // Load the published .nexe.  This includes the 'nexes' attribute which
      // shows how to load multi-architecture modules.  The relative URLs in
      // the following table should be matched with a similar directory
      // structure on your server.
      // TODO(dspringer): This feature is not yet supported in Chrome.  Pull
      // the src= attrib when this becomes available.
      var nexes = 'x86-32: hello_world.nacl/x86_32/hello_world.nexe\n'
                  + 'x86-64: hello_world.nacl/x86_64/hello_world.nexe\n'
                  + 'ARM: hello_world.nacl/arm/hello_world.nexe ';
      contentDiv.innerHTML = '<embed name="nacl_module" '
                             + 'id="hello_world" '
                             + 'width=0 height=0 '
                             + 'src="hello_world.nexe" '
                             + nexes
                             + 'type="application/x-nacl-srpc" '
                             + 'onload=moduleDidLoad() />';
    }
  </script>

[Invité]

ce qu'on appelle souvent des "FAT binaries"…

vous mettez ce que vous voulez dans un fichier…
simplement il faudra un loader adapté à ce format de fichier…

mais apparemment la solution de Google est de mettre les binaires dans une structure de directory…

Okay merci JeitEmgie

Le bout de code parle mieux qu'un long discours

[Invité]

D'après ce que j'ai compris, on a donc :

Un IDE genre eclipse ou plus probablement un codeblocks de chez google labs
Une série de cross-compilers : autant de portages de gcc que de processeurs cibles
Une arborescence de répertoires à copier sur le serveur (1 sous-repertoire = 1 proc cible)

Ensuite , au moment du GET HTTP (2 hypothèses)

1. Un code javascript teste la config hôte et charge le code natif correspondant
2. Le serveur http se débrouille pour analyser le get et décide lui même quelle version envoyer. Dans ce cas , il me semble quand même que l'info du get http est insuffisante, en particulier en ce qui concerne le matériel (seul l'os et le navigateur sont renseignés)

Une remarque : La compilation en mode release consiste en une série de compilations successives (une par config matérielle supportée), puis un upload de tous les .nexe, ??exe, ... Ce processus me semble bien lourd à effectuer si on inclut les archis embarquées ce qui devra bien arriver un jour...

Cela résout le truc qui m'a toujours embété en java : la résolution du multiplateformes au moment du runtime. Ici on résout tout au design time.
Selon moi, il n'y a pas d'autre moyen de mieux utiliser les cpu clients et donc produire une appli de même qualité que les applis locales installées via setup (ce dont java est incapable)

Outre le fait que mon esprit cartésien aime l'optimisation du c++, il faut dire aussi que ça s'inscrit très bien dans les efforts d'économie d'énergie qu'on demande à la fois aux datacenters et aux développeurs de solutions nomades (batterie).

Bref, ça n'a pas que des avantages mais moi je dis BANCO, c'est l'architecture du futur !! je déteste le gâchis qu'on a fait des ressources systèmes au nom de l'interopérabilité. Je préfère de très loin profiter des perfs des cpu's récents - sans pour autant vendre mon âme aux évangiles activeX et autres trucs ultra-propriétaires. Google est capable de faire consensus là où Ms n'a créé que des conflits. Même un pro-Ms est bien obligé de reconnaitre qu'il y a du bon dans le client en code natif, sauf à désavouer activeX