Google Chrome 14 disponible en téléchargement
Native Client et l'API Web Audio à l'épreuve du Web

Le , par Hinault Romaric, Responsable .NET
Mise à jour du 19 septembre 2011 par Idelways

Et de 14 ! Chrome engrange une nouvelle version majeure, marquée par deux importantes nouveautés : Native Client (NaCl) et le support de l'API Web Audio du W3C.

Cette dernière est une API JavaScript standard de haut niveau pour créer des effets audio au sein des applications Web, et même plus comme le démontrent les exemples de code publiés à l'occasion par Google.
On y trouve par exemple une boîte à rythmes, quatre synthétiseurs-oscillateurs et un visualiseur/analyseur des ondes sonores en WebGL.



Chrome 14 introduit aussi — comme décrit ci-devant — la technologie Native Client (NaCl) qui permet d'exécuter du code C/C++ à l'intérieur du navigateur dans un environnement protégé.

Cette technologie plutôt controversée est destinée à faire du navigateur une plateforme plus puissante pour les jeux 3D, l'édition vidéo et d'autres usages où JavaScript montre des limites notamment dans le cadre d'un système fondé sur navigateur à l'instar de Chrome OS.

En substance, le code Native Client s'exécute dans un bac à sable à double protection :
Par les registres de segments (segment registers), exploités pour restreindre les zones mémoires où le code peut lire et écrire, renforcés par un compilateur modifié et un mécanisme de vérification du code pour éviter les sauts du code hors de ses zones.

Native Client repose par ailleurs sur Pepper, une API qui applique au code C/C++ une interface identique à celle appliquée à JavaScript, et qui lui permet d’accomplir tout ce qui peut être fait avec.

Google voit dans Native Code une extension naturelle du Web, mais Opera et la fondation Mozilla ne sont pas de cet avis.
Mountain View développe par ailleurs Dart, un nouveau langage pour Web qui aurait pour ambition de remplacer le JavaScript qui ne convainc plus chez Google où il est considéré comme un frein de compétitivité face aux écosystèmes alternatifs (Apple App Store notamment).

Le SDK de Native Client est disponible et comporte en plus des fichiers d'en-tête nécessaires, les versions modifiées du compilateur GNU.

Exemples d'utilisation de l'API Web Audio
Télécharger le SDK de Google Native Client
Télécharger Chrome 14

Source : Blog de Chrome Chrome

Et vous ?

Avez-vous essayé Chrome 14 ? Que pensez-vous de ses nouveautés ?

Chrome 14 bêta disponible
avec le support de Native Client et l’intégration de l’API Web Audio

Chrome 14 bêta est disponible.

La principale nouveauté de cette version est l’intégration de la technologie Native Client (NaCl).

Native Client est un projet qui permet à des codes natifs de s’exécuter dans le navigateur. Le but est de permettre le développement d'applications Web reposant sur d’autres langages que le JavaScript ou le HTML5.

À ce stade, la plateforme supporte le C et le C++. Des développeurs indépendants ont également mis au point des plugins qui permettent la prise en charge de langages supplémentaires comme le Tcl (Tool Command Language).

"Artic Sea", le SDK qui permet la conception des applications Web C et C++ pour Chrome a déjà été publié. Et le développement d’un plugin pour la prise en charge de NaCl dans les environnements de développement Visual Studio et Eclipse est en cours par Google.

Reste que l'arrivée du code natif dans le navigateur est une avancée qui fait polémique dans la communauté.

Autre nouveauté importante de Chrome 14 bêta : l’introduction d’une nouvelle API JavaScript baptisée « Web Audio ». Cette API offre des capacités audio avancées et supporte les effets audio comme la simulation des scènes audio spécialisées complexes.

On notera également la correction de plusieurs failles de sécurité.

Et l'intégration de la fenêtre d’aperçu avant impression pour les utilisateurs de Mac OS X.

Télécharger Chrome 14 bêta

Source : Blog Chrome

Et vous ?

Que pensez-vous de ces nouveautés ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de ArKam ArKam - Membre éclairé http://www.developpez.com
le 16/08/2011 à 15:50
Citation Envoyé par Uther  Voir le message
J'ai l'impression que tu mélanges un peu tout:

- Ça n'a rien à voir avec CGI qui est une technologie coté serveur. "Native Client" comme son nom l'indique est une technologie coté client. C'est le navigateur qui exécutera un fichier "nmf" comme il exécuterait un "swf" flash, via la balise <object>.
La différence est juste que le code cotenu dans fichier nmf n'est pas (pseudo-)interprété comme Flash mais compilé.

Si tu veux plus de détails regarde le site de NaCl : http://code.google.com/intl/fr/chrom..._overview.html

- Pour ce qui est de la lourdeur des pages, un code compilé sera probablement moins lourd que l'équivalent Javascript (surtout s'il y en a beaucoup). Mais de toute façon, je ne pense pas vraiment que ce problème joue de manière déterminante pour où contre l'utilisation de NaCl.
Ce qui pèse vraiment, c'est généralement plus les données annexes (images, sons,...) que le code lui même.

Merci pour ces infos, j'avais déjà visité ce site mais je n'avais pas compris ce que c'etait.

Effectivement, ça peux devenir intéressant, par contre, j'ai peur que ça reste du coté de chez google et donc juste un + (marrant tiens) pour leur navigateur et surtout, que les webmaster vont encore devoir gérer plusieurs codes pour plusieurs navigateur.

Google ne pourrait pas faire une soumission de normalisation auprès du W3C ou autres?

Encore une question, est-ce que NaCL est une API C++ de chrome, ou bien tu peux écrire n'importe quel code? Si c'est le cas, ça risque d’être tendu niveau sécurité non?
Avatar de Uther Uther - Expert éminent http://www.developpez.com
le 16/08/2011 à 18:38
Citation Envoyé par ArKam
Google ne pourrait pas faire une soumission de normalisation auprès du W3C ou autres?

Ils auraient bien souhaités que d'autres navigateurs l’adoptent, mais c'est mal parti :
- il y a peu de chance que le W3C le soutienne car le code natif est dépendant de l'architecture.
- Mozilla et Opéra s'y sont résolument opposé pour cette raison.
- Internet Explorer a déjà l'ActiveX.

Comme tu le dis, cela restera une techno Google. Elle ne sera vraiment intéressante que pour faire des applications pour ChromeOS.

Citation Envoyé par ArKam
Encore une question, est-ce que NaCL est une API C++ de chrome, ou bien tu peux écrire n'importe quel code? Si c'est le cas, ça risque d’être tendu niveau sécurité non?

En effet le code est natif mais il n'aura accès qu'aux API de NaCl.
Il ne peux pas accéder directement aux API systèmes pour des raisons évidentes de sécurité.
Avatar de ArKam ArKam - Membre éclairé http://www.developpez.com
le 16/08/2011 à 22:24
Citation Envoyé par Uther  Voir le message
Ils auraient bien souhaités que d'autres navigateurs l’adoptent, mais c'est mal parti :
- il y a peu de chance que le W3C le soutienne car le code natif est dépendant de l'architecture.
- Mozilla et Opéra s'y sont résolument opposé pour cette raison.
- Internet Explorer a déjà l'ActiveX.

Comme tu le dis, cela restera une techno Google. Elle ne sera vraiment intéressante que pour faire des applications pour ChromeOS.

En effet le code est natif mais il n'aura accès qu'aux API de NaCl.
Il ne peux pas accéder directement aux API systèmes pour des raisons évidentes de sécurité.

Je trouve dommage les raisons de refus, pour activeX pareil, l'idée est pas mauvaise je pense à la base.

Pour ce qui est des accés je m'en doutais un peu, mais sait-on jamais j'ai préféré demandé.

Je trouve que Google essaye beaucoup de choses en ce moment, je trouve ça bien, microsoft pareil, ils essayent de redoré leur blason.

Concernant google, meme si ils ont les travers d'une grosse boites, je trouvent qu'ils s'en sortent plutot bien niveau communication, et R&D en ce moment, en plus ils gardent tout de meme un certain niveau d'ouverture (niveau code source et autres) que je trouve appréciable en ces temps de patent troll à tout vas.

Bref, j’espère qu'ils vont continuez dans ce sens
Avatar de Uther Uther - Expert éminent http://www.developpez.com
le 16/08/2011 à 22:50
Citation Envoyé par ArKam  Voir le message
Je trouve dommage les raisons de refus, pour activeX pareil, l'idée est pas mauvaise je pense à la base.

Je trouve au contraire que c'est une très bonne raison. C'est moins grave que l'ActiveX qui rend complètement dépendant de Windows, mais ça reste un sacré problème car il rend dépendant de l’architecture (x86, x64, PowerPC, ARM, ...).

Avec l'arrivé de HTML5, et des moteurs Javascript JIT puissants, on commence enfin à pouvoir se débarrasser doucement de ces saloperies que sont Flash et ActiveX, c'est pas pour se retrouver avec une nouvelle techno intrinsèquement contradictoire avec le cross-plateforme.
Avatar de Alpha573 Alpha573 - Membre régulier http://www.developpez.com
le 17/08/2011 à 18:25
Citation Envoyé par Uther  Voir le message
Pour moi le plus gros problème est que c'est une technologie non standardisée qui ne sera jamais supportée que par Chrome. Et même si d'autres navigateurs l'adoptaient, il rend dépendant de l'architecture de la machine, ce qui est contraire à la direction souhaitée pour le Web.

Totalement d'accord avec toi, c'est vraiment génant.
Pendant un moment je trouvais ça interessant et je voulais commencer à développer sur Chrome avec le SDK mais j'ai vtie laché l'idée, sachant que ça serait pas portable et standardisé... Dommage.
Avatar de Idelways Idelways - Expert éminent sénior http://www.developpez.com
le 19/09/2011 à 16:37
Chrome 14 disponible en téléchargement
Native Client et l'API Web Audio à l'épreuve du Web

Mise à jour du 19 septembre 2011 par Idelways

Et de 14 ! Chrome engrange une nouvelle version majeure, marquée par deux importantes nouveautés : Native Client (NaCl) et le support de l'API Web Audio du W3C.

Cette dernière est une API JavaScript standard de haut niveau pour créer des effets audio au sein des applications Web, et même plus comme le démontrent les exemples de code publiés à l'occasion par Google.
On y trouve par exemple une boîte à rythmes, quatre synthétiseurs-oscillateurs et un visualiseur/analyseur des ondes sonores en WebGL.



Chrome 14 introduit aussi — comme décrit ci-devant — la technologie Native Client (NaCl) qui permet d'exécuter du code C/C++ à l'intérieur du navigateur dans un environnement protégé.

Cette technologie plutôt controversée est destinée à faire du navigateur une plateforme plus puissante pour les jeux 3D, l'édition vidéo et d'autres usages où JavaScript montre des limites notamment dans le cadre d'un système fondé sur navigateur à l'instar de Chrome OS.

En substance, le code Native Client s'exécute dans un bac à sable à double protection :
Par les registres de segments (segment registers), exploités pour restreindre les zones mémoires où le code peut lire et écrire, renforcés par un compilateur modifié et un mécanisme de vérification du code pour éviter les sauts du code hors de ses zones.

Native Client repose par ailleurs sur Pepper, une API qui expose au code C/C++ une interface identique à celle exposée à JavaScript, et lui permettre d’accomplir tout ce qui peut être fait avec.

Google y voit dans Native Code une extension naturelle du Web, mais Opera et la fondation Mozilla n’en sont pas de cet avis.
Mountain View développe par ailleurs Dart, un nouveau langage pour Web qui aurait pour ambition de remplacer le JavaScript qui ne convainc plus chez Google où il est considéré comme un frein de compétitivité face aux écosystèmes alternatifs (Apple App Store notamment).

Le SDK de Native Client est disponible et comporte en plus des fichiers d'en-tête nécessaires, les versions modifiées du compilateur GNU.

Exemples d'utilisation de l'API Web Audio
Télécharger le SDK de Google Native Client
Télécharger Chrome 14

Source : Blog de Chrome Chrome

Et vous ?

Avez-vous essayé Chrome 14 ? Que pensez-vous de ses nouveautés ?
Avatar de Aiekick Aiekick - Membre éprouvé http://www.developpez.com
le 19/09/2011 à 21:18
Génial, enfin un browser qu'on va pouvoir hacker avec un des meilleurs outil qui soient à savoir le c++.

Je suis pas sure que leur sandbox va tenir longtemps.
Avatar de Lapinpanda Lapinpanda - Modérateur http://www.developpez.com
le 20/09/2011 à 10:36
Citation Envoyé par cuicui78  Voir le message
Génial, enfin un browser qu'on va pouvoir hacker avec un des meilleurs outil qui soient à savoir le c++.

Je suis pas sure que leur sandbox va tenir longtemps.

Je pense que Google est certainement plus malin que nous et à soigneusement étudier les risques avant de se lancer.
Avatar de Freem Freem - Membre émérite http://www.developpez.com
le 20/09/2011 à 11:48
La seule chose qui est certaine, c'est que les débuts risquent d'être dangereux si ça se popularise, sandbox ou pas, google ou pas. (Un système totalement sécurisé, ça n'existe pas)

Mais si le code est bien blindé, y'a pas de raison que ce soit facile.
En plus, les antivirus vont sûrement s'adapter, et je pense même qu'ils ont déjà certaines capacités à reconnaître les codes malicieux à l'exécution.

De toute façon, c'est bien d'intégrer une possibilité, mais il faut encore qu'elle soit utilisée. Si cette chose n'est supportée que par chrome, je suis presque prêt a parier que ça ne durera pas bien longtemps.
D'autant que comme précisé plus haut, la portabilité d'architecture risque d'être compiquée. (bien que du fait de la présence d'une API et du C++ même il sera possible de compiler pour diverses plates-forme sans toucher le code, mais il restera qu'il faudra bidouiller pour détecter l'archi et envoyer le bon code machine)
Avatar de lucideluciole lucideluciole - Membre habitué http://www.developpez.com
le 20/09/2011 à 15:39
Citation Envoyé par Lapinpanda  Voir le message
Je pense que Google est certainement plus malin que nous et à soigneusement étudier les risques avant de se lancer.

Pas tout à fait d'accord avec ça! Soigneusement étudié les risques peut-être, mais de là à croire que Google est plus malin...pas certain. Si c'était le cas, les failles de sécurité n'existeraient jamais.
Avatar de Aiekick Aiekick - Membre éprouvé http://www.developpez.com
le 20/09/2011 à 20:42
Citation Envoyé par Lapinpanda  Voir le message
Je pense que Google est certainement plus malin que nous et à soigneusement étudier les risques avant de se lancer.

Franchement face à des hackers qui ne vivent que pour trouver la faille, c'est utopique de penser ça.

Arrêtez de mettre Google sur un piédestal !!! C'est une société a but lucrative comme les autres.
Offres d'emploi IT
Chargé(e) de mission au CERT Société Générale (H/F)
Société Générale - Ile de France - Val-de-Marne
Développeur - software craftsman (H/F)
Société Générale - Ile de France - Hauts-de-Seine
Data scientist inspection générale (H/F)
Société Générale - Ile de France - Hauts-de-Seine

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique Accueil