Actualité éditeurs / SSII

• Sortie de RabbitMQ 2.0

Le coin de la technique

• Gestion automatique des ressources dans Java7 (ARM)

Evènements de notre communauté en France et à l'étranger

• Google et les brevets

Actualité éditeurs / SSII

Sortie de RabbitMQ 2.0

La sortie de la version 2.0 du serveur de messaging AMQP RabbitMQ vient d'être annoncée ici.
Cette release majeure vient avec une refonte importante et son lot de nouveautés :

• Une refonte de la gestion de la persistence permettant une alternative au moteur de persistence embarqué. Il sera possible de développer un support pour une base de données relationelle ou NoSQL ou tout autre data store.
• Le support de différents protocoles de messaging : AMQP (0-8 et 0-9-1), XMPP, STOMP, HTTP, SMTP... Il sera aussi possible d'ajouter de nouveaux protocoles à l'aide d'extensions.
• La mise en place d'une infrastructure ayant pour but de simplifier le développement d'outils pour la gestion et le monitoring de RabbitMQ.
• Une amélioration de la gestion des plugins (il n'est plus nécessaire de compiler les plugins, une version pré-compilée peut être directement chargée par RabbitMQ).

SpringSource qui a récemment racheté RabbitMQ (nous vous en avions parlé ici) propose de son côté un template reprenant les principes des templates jdbc, hibernate, jms ou encore LDAP encapsulant le client Java d'AMQP. Les utilisateurs habitués à JmsTemplate retrouveront donc leurs repères en utilisant l'AmqpTemplate du projet spring AMQP.

SpringSource/VMWare continue donc de faire évoluer son portefeuil de produits avec cette évolution majeure de RabbitMQ, qu'il considère comme une pièce essentielle à sa stratégie de développement du Cloud Computing (voir cet article de Rod Johnson).

Le coin de la technique

Gestion automatique des ressources dans Java7 (ARM)

Java7 suit son petit bonhomme de chemin sans qu'on ait encore une bonne visibilité sur la date de sortie officiel. Le build 105 de la version actuelle propose une nouvelle fonctionnalité très intéressante qui devrait facilité la vie de chaque développeur: l'Automatic Resource Management.

L'idée, proposée par Joshua Bloch depuis quelques années déjà, consiste à améliorer la fermeture des ressources sous la forme d'une clause try-with-resources. Actuellement lorsqu'on manipule une ressource, par exemple un InputStream, la façon la plus propre ressemble à ceci:

Ce code devient vite très verbeux et répetitif car beaucoup de vérifications doivent être faites pour s'assurer de la possibilité de fermer la ressource. La solution pour simplifier cela est de déléguer la fermeture du flux à l'aide du try:

Le code gagne énormément en visibilité, les tests pour savoir si la ressource est null ou si la fermeture s'est bien déroulée sont gérés en interne de la JVM. A noter que pour être fermées les ressources devront étendre une nouvelle interface AutoCloseable.

S'il existe un certain consensus autour de l'utilité de cette évolution, il demeure encore un petit débat sur la partie catch des exceptions. Sans rentrer dans les détails, les exceptions levées pendant la fermeture d'une ressource annihilent celles levées dans le bloc try, ce qui en général est préférable mais du coup peut aussi masquer des exceptions importantes pour l'analyse du problème.

Evènements de notre communauté en France et à l'étranger

Google et les brevets

Semaine chargée pour Google:

• InfoQ nous annonce que le MPEG LA a décidé de continuer à ne pas réclamer de royalties pour les videos encodées en H.264 et distribuées gratuitement aux utilisateurs. Seules les plateformes vendant des vidéos sont, elles, toujours soumises à taxation. C'est donc une réponse à Google qui avait il y a quelques temps annoncé WebM, un codec vidéo semblable au H.264 mais plus libre et débarrassé des problèmes de brevets et de royalties qui entravent ce dernier. Si InfoQ ne voit pas trop de problèmes à continuer d'utiliser H.264, ce n'est pas du tout l'avis de Mike Shaver ingénieur haut gradé chez Mozilla et qui rappelle que les logiciels permettant de produire ou de consommer ces vidéos devront eux toujours s'acquitter d'une licence. La bataille entre WebM et H.264 ne fait donc que commencer.
• Ensuite, c'est Paul Allen, le co-fondateur de Microsoft, qui attaque Google et nombre de ses petits camarades (AOL, Yahoo, Facebook) pour avoir enfreint 4 brevets détenus par sa compagnie "Interval Licensing". Le blog Digits du Wall Street Journal s'est penché sur 2 de ces brevets. Nous vous déconseillons fortement la lecture de son analyse si vous avez réalisé quoi que ce soit dans l'informatique ces 10 dernières années. En effet, vous risquez de ne plus trouver le sommeil en vous rendant compte que vous enfreignez sans doutes, vous aussi, nombre de brevets !
• Et pour finir sur Google et les brevets, vous vous souvenez des récentes poursuites engagées par Oracle concernant Java et Android. Google vient de riposter, en annoncant qu'aucun de ses employés ne participera à JavaOne cette année. Pour ceux qui voulaient échanger avec les employés de Google, il semble que c'est plus tard dans l'année, à Devoxx, qu'il faille se rendre. Mais rassurez vous, il y aura quand même de l'ambiance à JavaOne: James Gosling, père de Java, demande sur son blog à toute personne y assistant de porter un TShirt arborant le slogan "Java just Free it". Si cette idée ne risque pas trop de faire bouger Oracle, elle devrait quand même apporter sa dose de fun à l'évènement !

La revue de presse de l’actualité Java/J2EE hebdomadaire proposée par Xebia.

Actualité éditeurs / SSII

• Oracle poursuit Google pour violation de brevets

RIA

• Bean Validation pour Flex.
• Annonce de jQuery Mobile

SOA

• La NASA ouvre les sources de son cloud privé

Le coin de la technique

• Continuous Delivery, le livre le plus important de 2010 ?

Actualité éditeurs / SSII

Oracle poursuit Google pour violation de brevets

Jeudi dernier, Oracle a lancé une action en justice contre Google pour violation de brevets quant à l'utilisation de Java pour la plateforme Android. L'information a rapidement fait le tour du web et de la twitosphère provoquant à l'encontre d'Oracle son lot de commentaires indignés, notamment dans les communautés Java et libristes (On retiendra le billet peu amène de James Gosling : "The shit finally hits the fan....").

Dans sa plainte, Oracle précise que "Android [...] et les appareils qui utilisent Android violent un ou plusieurs brevets parmi les suivants: 6,125,447; 6,192,476; 5,966,702; 7,426,720; RE38,104; 6,910,205; et 6,061,520". Les brevets en question portent sur l'implémentation de machines virtuelles, l'outillage et les compilateurs.
Google, certainement pour garder les coudées franches, a fait le choix d'implémenter sa machine virtuelle Dalvik sans utiliser OpenJDK (la version GPL2 de Java). Cette implémentation n'est pas pleinement compatible Java et est exécutée sur des terminaux mobiles. Or, lorsque Sun avait "open sourcé une partie de Java" au travers d'OpenJDK, les garanties d'être à l'abri d'attaques pour violation de brevet ne protégeaient que les implémentations pleinement compatibles Java pour desktop et serveur uniquement (pas les implémentations pour terminaux mobiles).
Pour étayer son accusation selon laquelle Google a sciemment violé les brevets relatifs à Java, Oracle avance que Google était, de longue date, au courant des brevets détenus par Sun. Eric Schmidt (CEO de Google) et Urs Hölzle (Senior VP of operations chez Google) ont en effet joué un rôle significatif dans le développement de la technologie Java lorsqu'ils étaient chez Sun.
La réponse de Google à l'attaque d'Oracle (au travers d'un communiqué de presse) est sans surprise : Google estime que la plainte est sans fondement. D'autre part, Google considère qu'avec cette plainte, Oracle n'attaque pas seulement Google, mais aussi la communauté Open Source Java.

A priori, l'objectif d'Oracle n'est pas de "tuer" Android mais de profiter de son succès en imposant à Google de lui reverser une part des revenus de la plateforme. En effet, Java ME est une source non négligeable de revenus pour Sun (Oracle) puisque cette technologie équipe de très nombreux terminaux. Mais le succès fulgurant d'Android sur le marché des smartphones est sur le point de tarir cette source de revenus.
D'autre part, Oracle souhaite sans doute envoyer un message clair quant à sa conception de l'utilisation de la technologie Java là où le silence de Sun vis à vis d'Android pouvait être perçu comme un blanc seing.

Ce genre d'affaire est généralement synonyme de feuilleton judiciaire à rallonge (comme dans le cas emblématique de SCO vs. Linux). Il y a donc peu de chances que le cas Google / Oracle se règle rapidement. La complexité du dossier (notamment en ce qui concerne les tenants et aboutissants techniques) laisse présager de longs débats. Même si l'issu d'un procès reste incertaine Google était certainement préparé à une telle attaque (et est de taille à y faire face) et sa défense sera bien préparée.
Tant que l'affaire ne sera pas réglée, l'ensemble de l'écosystème Android (constructeurs, développeurs, utilisateurs, ...) va retenir son souffle, mais l'engouement pour la plateforme Android ne devrait pas trop en pâtir. D'une part, Google continuera de développer la technologie Android. D'autre part, gageons que Google prendra ses responsabilités sur le sujet de la propriété intellectuelle et jouera son rôle de pare feux vis à vis des constructeurs équipant leurs terminaux de l'OS Android.

La fin d'Android est très peu probable. Oracle n'y a aucun intérêt et ce pour plusieurs raisons. D'abord parce qu'Oracle a tout intérêt à ce que Java soit présent sur le marché des smartphones. Or cette présence passe par Android, pas par Java ME et Oracle n'a, aujourd'hui, ni la volonté, ni la capacité d'innover dans ce sens. Ensuite parce que l'essor des smartphones sous Android favorise le développement d'applications utilisant des backend (serveurs) mettant en œuvre des serveurs d'applications Java et des bases de données, augmentant ainsi la taille d'un marché sur lequel Oracle se taille la part du lion. Enfin parce qu'Android réunit une large communauté Java.
Il semble donc que cette affaire ne puisse avoir que deux issues :

• Google sera contraint à verser une partie des revenus d'Android à Oracle. Soit parce qu'Oracle aura gagné un procès, soit parce que Google aura préféré négocier un accord à l'amiable.
• Ce sera le status quo. Soit parce qu'Oracle aura perdu un procès, soit parce qu'Oracle retirera sa plainte suite aux négociations qui vont s'entamer (au cours desquels Google pourrait commencer à utiliser ses brevets comme arme de dissuasion).

Ce qui est sûr, c'est que l'image de Java ne sortira pas grandie de l'initiative d'Oracle (qui semble d'ores et déjà avoir perdu la bataille de l'image).

Pour ceux qui souhaitent approfondir le sujet, l'excellent billet de Charles Nutter "My Thoughts on Oracle v Google" fait longuement le tour de la question et propose des perspectives très intéressantes.

RIA

Bean Validation pour Flex.

Le framework GraniteDS continue à offrir des fonctionnalités riches pour Flex, en parallèle des offres de Adobe, BlazeDs (open source) et LifeCycle ES (commercial).
La version 2.2 (actuellement en bêta publique) ne faillit pas à la règle et amène une rafraichissante innovation : l'implémentation de la JSR 303 (BeanValidation) pour Flex. Toutes les contraintes standard de la JSR sont implémentées via des annotations AS3 et le générateur de code maison (GAS3) permet la conversions des annotations des beans Java.
La validation s'appuie sur une nouvelle fonctionnalité de réflexion.
Autre avancées, peut être moins spectaculaire, la prise en compte des types 'big numbers' de Java dans les sérialisations offertes par le framework.
GraniteDs, dont certains avait décrété la mort à la publication de BlazeDs, est toujours bien vivant et comble, en open source, certains manques laissés par Adobe.

Annonce de jQuery Mobile

C'est une nouvelle qui va à coup sûr faire du bruit dans un monde du développement mobile déjà bouillonnant, puisque vient d'être annoncée la sortie pour la fin d'année de la version mobile du framework jQuery. Et ce n'est pas par la petite porte que le célèbre framework web souhaite faire son entrée, puisque contrairement à ses concurrents déclarés, tels que jQTouch ou bien Sensha Touch, jQuery Mobile se veut être un framework JavaScript ciblant la quasi totalité des plateformes mobiles web actuelles (Blackberry, Windows Mobile, iOS pour l'iPhone et l'iPad, Android, Symbian, Bada, ...), et permettant de développer des interfaces riches capables de faire rougir bon nombre d'interfaces graphiques natives.

Avec l'avènement d'HTML5 (WebStorage, WebSockets, Vidéo, Géolocalisation, ...), du CSS3, et des navigateurs mobiles dernière génération proposant des moteurs JavaScripts performants, la guerre du web semble se trouver un nouveau terrain de bataille, et le web mobile aura sous peu toutes les armes nécessaires pour déstabiliser le business modèle à peine naissant des Markets, tel que l'iTunes App Store ou bien l'Android Market. Le marché des applications mobiles semble donc suivre la voie de son grand frère, celui des applications PC, et proposera à terme de nombreuses applications riches directement par le web.

L'annonce parue sur le site de jQuery Mobile indique que l'un des objectifs du framework est de pouvoir développer une application unique pour toutes les plateformes mobiles. Ce concept, ne semble pas nouveau puisque l'objectif de J2ME sorti il y a 10 ans déjà était bien de développer une solution unique, rappelez-vous: "Write Once, Run everywhere". Le slogan semble être ici: "Write Less, Do More", mais l'objectif de fond est bien le même.

Palm avec sa plateforme WebOS et Firefox sont déjà sponsors du projet. Bien qu'encore en développement intense, la première sortie est prévue pour fin 2010. Ce framework pourrait bien être une des grandes surprises mobile de 2010 et devenir très rapidement un incontournable pour le développement web d'applications riches pour mobile.

Pour en apprendre plus sur cette déclinaison de jQuery, vous pouvez suivre les liens suivants et apprécier les designs présentés :

• Site officiel de jQuery Mobile
• La device support grid de jQuery Mobile
• Les designs concepts

SOA

La NASA ouvre les sources de son cloud privé

La NASA a récemment annoncé son intention d'offrir le code de son cloud privé Nebula au projet OpenStack en partenariat avec Rackspace. Il s'agit d'une implémentation d'une IaaS orientée vers le calcul scientifique et le stockage de données. Par ailleurs OpenStack est un projet actuellement supporté par plus de 25 firmes, dont Dell et Intel. Il offre une pile logicielle ouverte permettant de créer et exploiter un cloud privé sur la base d'infrastructures matérielles standards. Il est disponible sous la licence Apache 2.0. D'après la présentation du projet, la création d'un nouveau Framework ouvert pour le cloud est motivée par deux raisons principales :

• Le paysage du cloud est actuellement composé d'offres propriétaires, incompatibles entre elles et manquant de transparence, freinant ainsi l'expansion de cette nouvelle industrie. La création d'un framework Open Source permettrait donc une adoption plus massive.
• La plupart des autres projets Open Source existant ne pouvaient satisfaire les énormes besoins de scalabilité exprimés par Rackspace. Seule Nebula, semblait correspondre au besoin.

Pour l'instant le projet est disponible en "Developer preview". Une première release sera disponible respectivement mi-septembre pour "OS Compute" et mi-octobre pour "OS Storage".

Le coin de la technique

Continuous Delivery, le livre le plus important de 2010 ?

Continuous Delivery, le livre de Jez Humble et David Farley, est disponible en version finale, en édition papier ou électronique (chez vos revendeurs habituels). Il traite d'un sujet qui tient à cœur de plus en plus d'acteurs de l'écosystème JEE : comment améliorer et dédramatiser les processus de build, de livraison et de déploiement d'un produit. Ce livre recueille déjà de nombreux lauriers. Dont ceux de Martin Fowler (directeur de la collection, donc forcément un peu partial), qui en fait le livre technique le plus important de 2010.

De ce que nous avons pu en lire (par exemple, en RoughCuts ici), ces louanges sont justifiées : ce livre traite de tous les problèmes qui devraient animer n'importe quel consultant au démarrage d'un projet. Collaborer entre équipes, développer de manière incrémentale, tester, automatiser, déployer, tout cela dans un seul but, maximiser la qualité du produit délivré.

Ce livre donnera lieu a un grand nombre de présentations en conférence, qui, si ce n'est déjà fait, devrait vous donner envie d'en faire votre livre de chevet avant la rentrée littéraire.

Pour en savoir plus, consultez le blog Continuous Delivery

La revue de presse de l’actualité Java/J2EE hebdomadaire proposée par Xebia.

Actualité éditeurs / SSII

• Naufrage pour Google Wave

Le coin de la technique

• Nouvelle architecture de réplication et de sharding pour MongoDB
• Axon, une implémentation Java du pattern CQRS
• L'architecture de Last.fm basée sur HornetQ

Actualité éditeurs / SSII

Naufrage pour Google Wave

Nous l'apprenons sur The H, Google Wave coule et ne sera bientôt plus. Après un peu plus d'un an d'existence, Google a décidé de mettre fin à son expérimentation qui n'aura pas répondu à toutes les attentes qu'elle avait provoqué. Pourtant, nous-mêmes, nous y avons cru ! Basé sur des protocoles ouverts, le système avait de quoi séduire, même si tout le monde se demandait un peu quelles allaient être les applications réelles... Las, les serveurs de Google devraient être fermés l'année prochaine. La firme annonce quand même la mise à disposition future d'outils permettant aux utilisateurs de "libérer leurs données de Wave". Mais ne nous y trompons pas, même si l'interface graphique colorée ayant donné aux internautes un avant goût de la communication du futur disparaît, il reste quasi-certain que le mécanisme d'échange de données entre serveurs Wave devrait survivre et servir de base à d'autres projets.

Le coin de la technique

Nouvelle architecture de réplication et de sharding pour MongoDB

MongoDB est une base de données orientée documents très populaire ces temps-ci. 10gen l'entreprise Open Source qui en est à la source se montre très active tant sur la communication que le plan technique en apportant des améliorations régulières pour placer leur base de données NoSQL à la hauteur des ambitions qu'on lui prête.
Respectant le planning présenté mi-juin lors du MongoDB Day à Paris, la version 1.6 vient d'être finalisée. Cette release estivale était particulièrement attendue car elle apporte des améliorations majeures sur l'architecture distribuée de MongoDB :

• La réplication était jusqu'alors assurée par une architecture master / slave qui souffrait d'un single point of failure à cause de son nœud master. MongoDB 1.6 introduit la notion de replica set qui est un ensemble de nœuds qui possèderont des replicas d'une même donnée. Une élection de master permet alors de définir un nœud unique qui sera responsable des écritures.
• Le sharding est maintenant production ready dans MongoDB. L'architecture de partitionnement repose sur un ou plusieurs nœud proxy intermédiaire entre les clients et les instances MongoDB.

En apportant ces améliorations, 10gen offre à MongoDB une architecture distribuée plus attrayante. Ce choix se comprend puisque MongoDB ne proposait jusqu'alors que des mécanismes peu innovants et qui poussaient beaucoup de projets à lui préférer Cassandra.

Axon, une implémentation Java du pattern CQRS

Le Command Query Request Segregation (CQRS) est un pattern architectural qui a été formalisé fin 2009 par Greg Young et Udi Dahan. Il repose sur l'idée de séparer le code métier selon qu'il s'appuie sur des opérations d'écriture (command) ou de consultation de données (query), plutôt que par découpage fonctionnel. Le but recherché ici est d'offrir une grande scalabilité en permettant aux lectures de s'effectuer de manière synchrone dans un cache, tandis que les requêtes d'écritures sont effectuées de manière asynchrone en mettant à jour à la fois le cache et la base de données sous-jacente.

Les développeurs Java disposent d'une implémentation Open Source de ce pattern, il s'agit du framework Axon (anciennement CQRS4J). Le projet est très actif et vient diffuser une version 0.6 dont la maturité mérite de s'y attarder : gestion et persistance des évènements, intégration à Spring et gestion des transactions.
Ce framework reste modeste pour l'instant et ne couvre qu'un nombre limité d'environnements techniques mais à défaut de répondre à votre besoin il constituera un exemple d'implémentation intéressant à étudier.

L'architecture de Last.fm basée sur HornetQ

Tout le monde connaît Last.fm, le service de streaming et de recommandation de musique. La compagnie a récemment changé son infrastructure de streaming et en a profité pour adopter JBoss HornetQ comme serveur de messaging, au détriment "d'un autre serveur open-source" (mais nous ne saurons pas lequel !). Jeff Mesnil publie sur DZone un article expliquant les raisons de ce changement et la façon dont Last.fm se sert d'HornetQ.
Pour résumer simplement, les messages JMS sont générés principalement par les streamers pour:

• notifier la fin de l'écoute d'un morceau et donc faire mettre à jour la base.
• permettre la déconnexion automatique d'un utilisateur connecté à un flux si un message généré par un second streamer indique qu'il vient de se connecter à un autre flux.

Dans sa configuration de HornetQ, Last.fm a mis l'accent sur la performance:

• la persistance a été désactivée. Comme rapporté par nos lecteurs dans les commentaires d'un précédant article celle-ci est connue pour être consommatrice.
• messages déclarés comme pré-acquittés, permettant d'éliminer des accès réseau supplémentaires.

Bien sûr tout ceci est fait au détriment de la robustesse. On n'a rien sans rien ! Mais Last.fm préfère perdre des messages plutôt que d'empêcher un auditeur d'écouter sa musique: "Availability was more important than reliable delivery". Il est à noter que pour renforcer la robustesse, les envois de messages ne sont pas faits n'importe comment: un seul thread s'occupe de la communication JMS. Il communique avec les autres threads en interne par un mécanisme de files, dans lesquelles il puise les messages à envoyer à HornetQ et dépose les messages reçus. Ces files étant limitées en mémoire, cette dernière est donc maîtrisée et comme il y a un seul thread responsable des accès JMS, il n'y a pas de risque de blocage de tout le système.

Pour continuer sur HornetQ, notons que la tant attendue interface REST vient d'être annoncée par Bill Burke, son développeur principal, sur le forum du broker. Cette interface n'est pas encore disponible dans une version officielle de HornetQ, mais sa documentation permet d'ores et déjà de se faire une idée. Basée directement sur HTTP, elle évite de forcer l'utilisation d'une quelconque encapsulation (autre qu'applicative) des messages. Et bien sûr, on peut l'utiliser avec n'importe quel langage: REST est interopérable. La documentation spécifique à la création de messages permet de se faire une idée rapidement. Basée sur RestEasy, qui fera aussi partie du futur JBoss AS 6, il y a fort à parier que cette interface fera parler d'elle et ouvrira la voie à de nouvelles utilisations du broker.

Google I/O

• Partenariat entre Google et VMWare
• App Engine For Business
• WebM: enfin un standard vidéo libre ?

SOA

• Les créateurs de jBPM chez Alfresco

Le coin de la technique

• MyBatis : un fork de iBatis chez Google Code
• JRuby 1.5.0

Google I/O

Dans le foisonnement d'annonces lors du Google I/O 2010 qui s'est tenu la semaine dernière à San Francisco, nous en avons retenu quelques unes très intéressantes.

Partenariat entre Google et VMWare

VMWare et SpringSource sont décidément très actifs actuellement dans le domaine des partenariats et des acquisitions (RabbitMQ, GemStone ou VMForce). Google I/O a été l'occasion pour eux d'annoncer un nouveau partenariat autour du cloud computing, voire au delà: ils poussent plus loin leur concept d'Open PaaS déjà évoqué pour le partenariat avec SalesForce.

L'idée sous-jacente est de faire de VMWare la plateforme de développement privilégiée pour toute solution de PaaS (Plateform as a Service). En citant Steve Herrod, CTO chez VMWare:

Developers must be able to write applications without needing to know what underlying technology powers the cloud that they'll be deployed on.

Et donc on pourrait développer une application App Engine et la tester sur les environnements de Google puis les déployer en production sur des instances VMWare. Au-delà de la problématique de l'hébergement, Steve Herrod ajoute également la possibilité d'accéder aux services Google (géolocalisation, traduction automatique...) et de diversifier les supports, en particulier sur les smartphones. Ce sont deux notions qu'on retrouve également dans le partenariat avec SalesForce.

Tout cela constitue pour l'instant des vœux pieux. Rod Johnson nous donne un aperçu plus précis de ce que sera ce partenariat:

• Intégration de GWT à l'outil Spring ROO, l'outil de SpringSource Tool qui permet de générer des projets Java en ligne de commande.
• Intégration de Google Speed Tracer à Spring Insight. Speed Tracer est un très bon outil de mesure de performance côté client, disponible aussi comme extension de chrome, alors que Spring Insight est un outil de mesure de performance plutôt côté serveur et directement accessible dans SpringSource Tool Suite. L'association des deux semble assez naturelle.

Il est encore difficile de voir la pertinence de ce nouveau paradigme, l'Open PaaS, et si l'hétérogénéité des solutions ne va pas le rendre un peu creux. Mais au-delà de ça, la stratégie actuelle de VMWare semble être la captation des développeurs Java vers leurs outils et en particulier SpringSource Tool Suite.

App Engine For Business

Au-delà du partenariat avec VMWare et alors qu'aujourd'hui App Engine a encore une étiquette (un peu) de bricolage, Google a la volonté de percer dans les entreprises et d'ajouter tout un arsenal prompt à rassurer celles qui voudraient se lancer. D'où la nouvelle offre Google App Engine For Business qui s'articule autour de ces points:

• Administration centralisée : cette console permettrait de gérer, entre autres, plusieurs projets d'une même entreprise.
• Fiabilité et support : une garantie de SLA de 99.9% et support pour les utilisateurs.
• Sécurisation par défaut : l'application serait par défaut sécurisé par les comptes Google App de l'entreprise.
• Coût raisonnable : la plateforme serait disponible pour 8$ par utilisateur et par mois, plafonné à 1000$.
• une architecture plus orientée entreprise : utilisation du SSL à l'intérieur du domaine de l'entreprise, utilisation des services avancés de Google et surtout enfin accès à des bases SQL (c'était un des gros points noirs d'App Engine). Ces nouveautés seraient disponibles dans le courant de l'année.

Plus de détails ici.

WebM: enfin un standard vidéo libre ?

Le Google I/O a aussi été l'occasion pour le géant de faire une annonce que de nombreux partisans d'un internet ouvert espéraient depuis le rachat de la société On2. Jusqu'à présent, les formats vidéo "du futur" étaient d'un coté H264, et de l'autre Theora. H264, meilleur techniquement que Théora avait le gros désavantage de traîner derrière lui nombre de brevets. Le consortium gérant ce format avait déclaré ne pas désirer recevoir de royalties avant quelques années. Mais le format n'en restait pas moins propriétaire et l'épée de Damoclès des royalties était susceptible de s'abattre plus tard sur ses utilisateurs. Cette guerre commençait à devenir visible au niveau des navigateurs et de leur support de la balise video du HTML5. Pour rappel, la spécification de celle-ci n'impose aucun codec. Nous arrivions donc à une situation difficile où certains navigateurs ne supportaient que Theora (Firefox) et d'autres que le H264 (Safari). L'incertitude était de mise quant à préserver un web standardisé mais ouvert. C'est là que Google intervient en proposant un nouveau projet, WebM, et endosse son costume de sauveur du web.
Ce projet est destiné à développer un format vidéo libre. Techniquement, des fichiers WebM contiendront:

• de la vidéo au format VP8
• du son en Vorbis
• le tout dans un conteneur Matroska.

Certaines voix se sont d'ores et déjà élevées pour dénoncer le format VP8 pour diverses raisons, mais il y a fort à parier que ce codec soit celui que tout le web attendait, notamment pour utiliser la norme HTML5 sans soucis de compatibilité. Les versions de développement de Firefox et Chrome intègrent déjà le support de ce format, les mobiles Android devraient le faire avant la fin de l'année et Adobe, avec Flash, suivra aussi.

A coté de l'aspect technique, il nous semble intéressant de nous attarder sur la licence de WebM qui est assez singulière et participera à n'en pas douter à imposer WebM. L'un des problème de ce projet est que, malgré toutes les dispositions prises, il n'est pas certain qu'un bout de code quelque-part n'enfreigne pas un quelconque brevet... Or, la licence stipule, en gros, que quiconque intentera un procès au projet ou à ses utilisateurs devra cesser d'utiliser le projet lui-même. C'est un coup de génie: si WebM commence à s'imposer (ce dont nous ne doutons pas avec la puissance de feu de Google, Youtube...), alors les entreprises susceptibles de lui intenter un procès ne le pourront pas, car elles seront en même temps obligées de l'utiliser elle-mêmes pour ne pas pénaliser leurs propres utilisateurs. Impossible d'imaginer les utilisateurs d'Opera interdits de Youtube pour cause de format vidéo non supporté par exemple: ils auraient tôt fait de migrer vers un autre navigateur. Google tient donc peut être, avec WebM, le nouveau standard vidéo du Web. En tout cas, il entend bien l'imposer comme tel.

SOA

Les créateurs de jBPM chez Alfresco

Alfresco a annoncé son nouveau BPMS, Activiti, mené par le créateur de jBPM, Tom Baeyens, et de son ancien lead developer Joram Barrez, tous deux partis de chez JBoss il y a peu.

A l'instar de jBPM, Activiti est un BPMS léger, qui s'intègre facilement à nos applications Java. Il propose en plus, une console d'administration et un modeler graphique en ligne.

Par ailleurs, il s'appuie sur le standard BPMN 2.0, et bénéficie ainsi à la fois d'une sémantique d'exécution, ainsi que d'un modèle de représentation graphique. Cette décision marque bien le contraste avec le choix précédent des créateurs, lors du développement de jBPM, de s'appuyer sur un format propriétaire, jPDL.

L'éditeur de la célèbre solution ECM a toutefois annoncé qu'il continuerait le support de jBPM au sein de sa suite logicielle. Bonne nouvelle, pour les nombreux projets qui ont déjà investi dans la solution de jBoss.

On notera enfin que SpringSource annonce la collaboration de Dave Syer, project lead de Spring Batch, avec l'équipe d'Activiti. On devrait donc s'attendre à un prochain support de BPMN dans les applications Spring.

Le coin de la technique

MyBatis : un fork de iBatis chez Google Code

Alors que la version 3.0 d'iBatis a été finalisée il y a un mois après une longue période de gestation, une annonce majeure pour l'avenir du projet vient d'être diffusée sur son site. Le créateur d'iBatis, Clinton Begin, ainsi que plusieurs des principaux commiters ont décidé de créer un fork du projet en dehors de la fondation Apache.

Ce nouveau projet est baptisé MyBatis et est hébergé sur Google Code. Le projet iBatis d'origine est conservé au sein de la fondation, mais stoppé. Il devient donc un sous-projet d'Apache Attic qui regroupe les projets Apache dépréciés.

Clinton Begin clarifie les principales questions que l'on peut se poser suite à cette annonce :

• Les noms des packages ne changent pas, et la compatibilité ascendante est préservée avec le passage à MyBatis.
• Les branches 2.x et 3.x sont préservées dans MyBatis avec la disponibilité immédiate des versions 2.3.5 et 3.0.1.
• La licence est conservée.

Cette annonce est pour le moins inattendue mais dans la mesure où il s'agit d'un transfert de responsabilité plus que d'un fork, les ressources du projet ne seront pas divisées et son activité devrait donc être préservée.

JRuby 1.5.0

Avec un peu de retard, nous tenons quand même à signaler la sortie de JRuby en version 1.5.0. Cette version a été celle de la maturation du moteur. En terme de compatibilité avec le langage Ruby, très peu d'ajouts ont été faits. En revanche, beaucoup d'ajouts de stabilité, améliorations de l'utilisation mémoire, du support de Windows, support de Ruby On Rails version 3. Pour le détail : l'Annonce officielle.

L'astuce de la semaine

Nous inaugurons aujourd'hui une nouvelle rubrique qui est destinée à vous faire part brièvement de petites astuces qui, nous l'espérons, pourront vous être utiles. Et c'est le tout récent Eclipse MarketPlace qui honore cette nouvelle rubrique de sa présence. Pour rappel, le MarketPlace est le successeur de Eclipse Plugin Central (maintenant en fin de vie) et destiné à lui ajouter de nombreuses fonctionnalités.
Dans son post, Zviki Cohen nous apprend comment utiliser le MarketPlace pour créer des liste de plugins et les installer facilement. C'est une astuce qui peut être particulièrement intéressante lorsque l'on cherche à uniformiser les postes de développement par exemple: il suffit d'une URL pour ajouter à une installation d'Eclipse tous les plugins utilisés. C'est une alternative pratique à l'installation manuelle par chaque développeur qu'on retrouve souvent sur les projets.

Sommaire

• HTML5 ?
• Nouveau modèle de contenu
• Nouveaux éléments de mise en page
• Eléments interactifs
• Les WebForms
  • Nouveaux input
  • Validation native
  • Auto-complétion
  • Répétitions
  • Etat des lieux
• Multimedia
  • Audio et Video
  • La guerre des Codecs
  • Le Canvas
• Conclusion

HTML5 ?

HTML5 est au départ la nouvelle version du langage HTML en cours de développement par le W3C. Pour le moment, il s'agit d'une recommandation en DRAFT, fruit du travail initial réalisé par le WHATWG depuis 2004. Le W3C espère en faire un de ses standards libres aux alentours de 2022. De prime abord, ça nous laisse le temps de réfléchir au problème pendant les 10 prochaines années. L'idée d'une nouvelle version de HTML serait motivée par quelques constats simples :

• Les navigateurs ont besoin de plugins pour gérer le multimédia (flash et consorts)
• La structure des documents n'est pas intuitive et rend l'accessibilité difficile
• Les API JavaScript varient trop d'un navigateur à l'autre pour garantir la portabilité des documents
• Les sites sont de plus en plus proches des applications de bureaux mais souffrent encore de limitations

Pour répondre à ces problématiques et favoriser l'émergence du web sémantique, la spécification propose :

• Un nouveau modèle de contenu des éléments
• Des éléments de mise en page
• De nouveaux éléments pour les formulaires
• Du contenu multimédia
• Plus d'interactivité
• Des APIs standards JavaScript

Bien que la spécification soit encore en cours d'écriture, certaines parties sont déjà très avancées et les navigateurs ont tous commencé à les implémenter. Google Chrome est actuellement en tête. Il bénéficie nativement de Gears et respecte 87% de la spécification. Parmi les principaux supporters de ce standard en devenir, nous retrouvons Google, Mozilla, Opera, Apple et Palm, pour ne citer que les plus grands. Apparemment, les navigateurs qui ont le vent en poupe sont tous de la partie. Microsoft, de son côté, suit la tendance de très loin en intégrant des fonctionnalités au compte goutte dans son IE, qui supporte tout de même 28% du langage.

Nouveau modèle de contenu

Bye, bye, les alignements hasardeux dus aux éléments de type bloc ou en ligne. Les éléments seront plutôt classés par catégories.

• La catégorie ancêtre Flow correspond à tous les éléments qui contiennent un flot de texte
• Phrasing correspond aux éléments qui apparaissent dans le texte (a, li)
• Interactive définit les éléments qui fournissent une interaction avec l'utilisateur
• Embedded affiche des ressource externes dans le document
• Les Metadata représentent tout ce qui n'est pas affiché (style, script, ...)
• Heading définit les en-têtes d'une section
• Sectioning définit le scope des en-têtes et pieds de page

Toutes ces catégories permettent de définir le contenu autorisé pour les éléments. Leur but est d'une part de fournir une grande souplesse de composition (par exemple la balise a peut maintenant contenir un paragraphe entier, une liste ou des headers (h*)), d'autre part ces catégories permettent aux navigateurs d'assimiler le contenu de la page, notamment pour les exports d'impression ou l'accessibilité.

Nouveaux éléments de mise en page

Jusqu'à maintenant, l'élément de mise en page par excellence était la balise div. La grande majorité des sites est construite sur un modèle d'empilement de ces boites avec des id différents pour finir par une grosse partie de styles CSS assurant le positionnement. Mais cela a quelques inconvénients:

• Ce n'est pas intuitif pour le développeur, vous en conviendrez.
• Le navigateur ne peut pas connaître le rôle de chacune des parties de la mise en page, ce qui rend beaucoup plus difficile la génération de plan ou d'aide à la navigation.

Les balises article, section, header et footer indiquent clairement à quel type de texte elles correspondent et comment s'organise leur contenu. La balise aside définit un contenu lié au sujet principal, sans en faire partie pour autant. Reste le tag nav qui est prévu pour servir les liens de navigations de la page comme un menu par exemple. La mise en page proposée ci-dessus ne révèle pas la flexibilité d'utilisation de ces éléments. Notez bien que les article et section peuvent avoir leur propre header et footer.

Avec ces nouvelles balises, nous serons enfin capables de gérer l'organisation de nos documents de façon intuitive et les navigateurs pourront générer le plan des documents eux-mêmes. L'algorithme nécessaire est d'ailleurs décrit dans la spécification. Tous ces éléments sont déjà supportés nativement par les navigateurs avec l'exception habituelle de IE pour lequel il existe un workaround JavaScript. Vous pouvez dès maintenant vous familiariser avec ces nouvelles balises sans avoir peur des problèmes de compatibilité.

Eléments interactifs

Sous ce terme limpide se cachent les éléments qui fournissent de l'interaction utilisateur dans la page. Ce qui correspond aux Interactive elements de la spécification. La grosse nouveauté ici est la définition d'une balise menu permettant de construire des barres de menu (type="toolbar"), des menus contextuels (type="context") ou de simples listes de commandes. Un tag menu peut contenir des sous-menus et se compose d'éléments permettant de lancer des commandes.

Pour les commandes, HTML5 propose directement un élément command qui permet d'associer un texte ou icône à une exécution JavaScript sur événement onclick="alert('hello world')". Pour utiliser le menu contextuel, il suffit d'ajouter l'attribut contextmenu="menu_id", sur l'élément qui doit utiliser le menu.

L'autre nouveauté parmi les éléments interactifs est la balise details. Le fonctionnement de ce tag est proche d'un menu en accordéon, avec une partie de texte toujours affichée et une partie cachée pouvant être rendue visible sur demande de l'utilisateur. Cela peut être utile, pour cacher des options avancées par exemple.

Ici, le tag details est utilisé pour cacher les informations techniques d'une copie. Vous noterez au passage l'utilisation d'une balise progress, pour afficher une barre d'avancement.

Les WebForms

Nouveaux input

Les formulaires aussi profitent de la mise à jour en reprenant en partie XForms pour les connaisseurs. Le principe est de fournir des input fortement typés ainsi qu'une API JavaScript de validation en plus d'une interactivité accrue. Parmi les nouveaux types d'input, il y a :

• Le support des saisies de dates et heure décliné sous plusieurs formes (date, datetime, datetime-local, month, week, time). Nous n'aurons donc plus besoin des widgets supplémentaires JavaScript pour générer des calendriers.
• La saisie de formats numériques via les number et les range qui pourront prendre la forme d'un slider vertical ou horizontal
• Différents types de chaînes formatées comme les url, les email et tel
• Le selecteur de couleur color
• Le champ de recherche search

Les anciens types sont maintenus. Ils bénéficient d'un bon lifting, tel le type file qui permettra désormais de sélectionner plusieurs fichiers d'un seul coup, tout en précisant le type mime accepté. Il y a aussi l'attribut placeHolder qui permet de fournir un texte descriptif affiché dans le champs si il n'est pas renseigné.

Validation native

Tous les input supportent de nouveaux attributs de validation qui permettent de contraindre les saisies de l'utilisateur, et peuvent interdire la soumission du formulaire, s'il n'est pas valide. Encore une fois, cela permettra de remplacer des solutions hétérogènes JavaScript par un standard nativement supporté par le navigateur. La validation s'accompagne aussi de nouveaux évènements DOM pour notifier les erreurs ou surcharger la validation avec son propre code JavaScript. Plus besoin non plus de jouer avec les classes CSS pour faire ressortir les champs en erreur grâce aux pseudo-formats (:invalid, :valid, :Out-of-range, ...).

Des validateurs par défaut sont fournis sous la forme de nouveaux attributs à placer sur les input :

• required pour un champ requis
• min et max permettent de définir une valeur minimum et maximum sur les types numérique et date
• pattern fournit une expression régulière que la saisie doit respecter

Auto-complétion

Autre nouveauté inspirée des widgets JavaScript existant, les datalist sont des listes de valeurs construites à l'aide d'éléments de type liste (li, option, ...). La datalist est transparente par défaut mais elle peut-être liée à un ou plusieurs input avec l'attribut list. Une fois l'association établie avec un input, la liste est utilisée pour fournir des suggestions à la saisie. Les éléments à l'intérieur de la liste peuvent-être décorés par CSS directement.

Répétitions

Une autre évolution sympathique est la création d'un système de template, facilitant la création de formulaire dynamique. Dans les applications de gestion, il est souvent utile de pouvoir ajouter et supprimer des lignes de saisie dans le formulaire. Le système de répétition est fait pour ça. Je peux définir un bloc comme étant mon template, et le contenu de cet élément pourra être dupliqué via une API JavaScript.

C'est l'attribut repeat qui définit notre bloc de répétition, le repeat-start permet de gérer les aller-retour serveur, pour afficher la liste avec le nombre d'éléments précédemment soumis. Pour assurer l'ajout et la suppression de ligne, j'ai utilisé les boutons de type add et remove mais j'aurais aussi bien pu utiliser des méthodes JavaScript de l'élément template addRepetitionBlock(). Il y a aussi des solutions pour gérer l'ordre des répétitions permettant de monter et descendre les lignes répétées.

Etat des lieux

Voilà la promesse d'un monde meilleur dans lequel nous aurons moins de travail à fournir (CSS, JS) pour obtenir des résultats simplement meilleurs. Notez une dernière chose, les input peuvent être liés à un ou plusieurs formulaires via le nouvel attribut form. En d'autres termes, il sera possible de placer nos input pour un formulaire à l'extérieur de ce dernier.

Comme vous l'avez remarqué, j'ai utilisé le futur dans ce paragraphe car pour le moment seul Opera 9 supporte nativement les WebForms. Pour permettre aux développeurs de s'y essayer et valider la spécification, le projet WebForms2 propose une implémentation partielle en JavaScript. La spécification au départ avait été séparée du langage HTML5, mais le W3C a décidé de la ré-intégrer en y apportant des modifications. Du coup la plupart des fonctions développées sont liées à une ancienne version des WebForms.

Pour les autres navigateurs, notez tout de même que les développements ont déjà commencé. Par exemple Chrome 5 devrait être livré avec le support des nouveaux input et l'API de validation(Chrome Web Platform Status). Safari bénéficie du même support que chrome qui se limite aux types search, range et file multiple. Du côté de Firefox, les choses sont moins claires ; il existe bien un ensemble de bugs pour le support des WebForms mais Mozilla communique peu sur le sujet. Actuellement, Internet Explorer 8 ne supporte aucune des ces nouveautés et il est impossible de connaître la roadmap de Microsoft sur le sujet. Tout ce que l'on sait, c'est que l'éditeur a décidé de mettre les bouchées doubles pour améliorer son support des travaux du W3C. Peut-être une bonne solution pour inverser la vapeur et en finir avec la descente aux enfers de son précieux navigateur.

Page de démonstration pour Chrome, Safari et Opera.

Multimedia

Il est temps de parler des nouveaux types de contenu poussés par HTML5. Les auteurs du whatwg se sont probablement demandé pourquoi doit-on installer des plugins dans nos navigateurs ? Nous savons a priori tous aujourd'hui que Flash est utilisé principalement pour 3 choses dans les applications :

• Pouvoir écouter de la musique
• Pouvoir regarder des vidéos
• Faire des animations de folies

J'ai mis volontairement de côté Flex car il cible plutôt les applications d'entreprise, et les jeux Flash car le Boss ne veut pas en entendre parler . Sachez, si vous êtes passé à côté de ça, que HTML5 adresse ces trois problématiques en sortant trois nouvelles balises de son chapeau :

• audio permet de gérer la lecture de fichiers audio en streaming.
• video assure la lecture de vidéos en streaming toujours.
• canvas permet de dessiner et de faire des animations en JavaScript.

Audio et Video

Jusqu'à maintenant, les gros avantages de la technologie d'Adobe sont la portabilité puisque Flash est disponible pour tous les navigateurs, et la performance en comparaison avec les moteurs JavaScript. Il est clair que ces trois balises viennent marcher sur les plate-bandes de Flash. Les éléments média disposent des attributs :

• controls pour activer l'affichage de l'interface de contrôle du navigateur
• autobuffer pour activer le chargement automatique de la ressource en cache
• autoplay pour activer le lancement automatique de la lecture
• loop pour lire le ou les médias en boucle
• src pour fournir l'url du fichier média à lire

La balise source placée à l'intérieure d'une balise audio ou video permet aussi de définir l'url (@src), le type mime et le codec (@type) d'une ressource média. Il suffit de mettre plusieurs source pour créer une playlist.

Si le navigateurs n'arrivent pas à lire le fichier ogg, il tentera de lire le fichier H.264. De même, si le navigateur ne supporte pas l'élément video, il affichera le texte alternatif. Il suffit donc de placer un lecteur Flash à la place du texte pour que la vidéo reste lisible dans un ancien navigateur.

Si vous ne voulez pas utiliser l'interface native, ou que vous souhaitez simplement cacher le lecteur audio, vous pouvez utiliser l'API standard JavaScript pour créer un lecteur, et profiter des méthodes play(), pause(), et load() pour charger la prochaine ressource média. Une dernière méthode : canPlayType(type), permet de demander au navigateur si il supporte le format vidéo ou audio fournit en paramètre. Cela sera très utile pour gérer les incompatibilités de format.

De plus l'interface HTMLMediaElement fournit quantité de propriétés allant du volume à l'état du buffer en passant par le temps de lecture courant. Le tout est, bien sûr, accompagné d'une batterie d'événements qui permettent de suivre l'avancement du chargement, l'état du lecteur, et les action lancées par l'utilisateur.

Pour plus de détail sur le sujet, je vous invite à lire la spécification W3C des éléments média et à tester la démo de jPlayer un lecteur audio pour jQuery.

La guerre des Codecs

Venons en au problème des codecs. Le W3C se contente de citer un certain nombre de formats allant du H.264 au DIRAC pour la vidéo en passant par mpeg-4 et Theora; même chose pour l'audio avec AAC, FLAC, Vorbis, ... La spécification laisse le libre choix aux navigateurs et table sur la création d'extensions propres à ces derniers pour apporter le support de nouveaux formats. Si aujourd'hui YouTube et Vimeo ont choisi le H.264, DailyMotion joue les fidèles Mozilla avec sa démo basée sur Ogg et ne supportant que Firefox.

Chrome et Safari poussent H.264 tandis que Mozilla le rejette totalement et pousse les formats libres Vorbis et Theora (Ogg). Le gros avantage d'H.264, à mon sens, tient au fait qu'il est parfaitement adapté à l'embarqué et beaucoup plus optimisé que Theora. Malgré le barrage de Firefox (25% de parts de marché), avec Apple et Google le codec H.264 semble avoir de beaux jours devant lui. Google qui est justement le plus gros contributeur de Mozilla, fournira peut-être une extension, sinon ce sera probablement du codec pack pour tous.

Codecs supportés par navigateurs

Internet Explorer est pour le moment hors-jeu, sauf si on installe Google Chrome Frame. Mais il semblerait que Microsoft s'intéresse au sujet pour l'avenir et participe à la rédaction de la spécification. En attendant, Flash conserve une avance confortable et profite de sa très large base installée. Le changement arrive bizarrement par l'embarqué, iPhone et iPod Touch en tête, qui, d'une part, supportent pleinement les balises audio, et video, et d'autre part prouvent que les utilisateurs peuvent se passer de Flash sur le web.

Le Canvas

Passons maintenant au canvas. Inventé par Apple pour le Dashboard d'OS X et ses widgets, le canvas fournit une API JavaScript pour le dessin 2D. La balise définit une aire de dessins avec sa hauteur et sa largeur. L'objet DOM donne accès au contexte graphique qui possède les primitives de dessins. Outre les formes géométriques standards, l'API permet de faire de la composition, des transformations, de manipuler des images et d'afficher du texte formaté. Avec un timeout ou un intervalle sur l'objet et un peu de JavaScript, il devient possible d'animer les dessins. Les implémentations ne sont pas encore très optimisées. Un simple gif animé reste pour le moment plus performant en terme d'animation. Il existe déjà un tas de librairie JS construites autour de l'élément canvas pour générer des graphes et des charts par exemple (Flotr, ProtoChart, fgCharting).

Les détracteurs déplorent l'utilisation d'une API procédurale, et l'absence d'éléments crées dans l'arbre DOM de la page comme le fait SVG. Autre inconvénient, canvas travaille la composition directement en pixels et non en calques. SVCKit a donc implémenté en grande partie SVG dans canvas dans SVGCanvas. Il existe déjà beaucoup de documentations et tutoriels autour de canvas qui rencontre, malgré ses défauts (de jeunesse ?), un grand succès. Mozilla a même développé un IDE en ligne basé sur canvas, nom de code : BeSpin.

Voilà pour les domaines d'application, passons maintenant à la question des navigateurs. Avec Apple pour inventeur et Mozilla comme évangéliste, canvas est déjà supporté nativement sur Safari, Firefox, Chrome et Opéra. Comme d'habitude IE est à la traine, mais il existe des contournements comme le plugin IECanvas, ou le portage Flash ExplorerCanvas.

Conclusion

Nous voici à la fin de ce tour d'horizon des nouveautés d'HTML5, côté contenu du moins.
Avec les grands du web dans la poche, HTML5 est déjà promis à un bel avenir, malgré son jeune age. La prochaine échéance du W3C devrait être le passage en recommandation dans le courant de cette année peut-être. Si les WebForms ne sont pas pour tout de suite, le multimédia et le canvas sont déjà suffisamment supportés pour être utilisés aujourd'hui. Il faudra attendre la sortie d'IE 9 pour connaître les plans concrets de Microsoft sur le sujet. A mon humble avis, Microsoft intégrera HTML5 au fur et à mesure qu'il s'imposera sur le web. Il faudra aussi regarder de près l'évolution du standard CSS car HTML5 ne va pas sans CSS3. De ce côté, pas de crainte à avoir puisque même IE est dans la course.

Il reste un problème d'outillage, car il n'existe pas pour le moment de WYSIWYG compatible HTML5. Et il ne faut sans doute pas compter sur Adobe pour le faire rapidement. Apple propose déjà DashCode pour créer des widgets ou des applications web iPhone avec un éditeur graphique bien monté. Mais l'export vers d'autres navigateurs est presque impossible tant les applications construites reposent sur des fonctionnalités spécifiques de Safari.

Dans le prochain article, je vous présenterai les nouveautés JavaScript poussées par HTML5 et leur état actuel d'implémentation.