Avertissement : cette note parle de jeux, un secteur auquel je ne connais strictement rien. Elle est donc sans doute bourrée d’erreurs, n’hésitez pas à me les signaler, merci.

Mozilla et Epic Games avaient créé la sensation en Mars en présentant Epic Citadel, un jeu qui fonctionne dans le navigateur. Epic Citadel utilise le moteur de rendu Unreal Engine 3, écrit en C++. Le code de celui-ci a été converti en JavaScript via Emscripten, et s’exécute pratiquement sans perte de performances dans les versions nocturnes de Firefox grâce à son moteur JavaScript optimisé pour asm.js. Cette démonstration est enfin disponible en ligne et vous pouvez la tester. Pour l’instant, du fait de bugs dans les implémentations de WebGL des autres navigateurs, elle ne semble malheureusement fonctionner parfaitement que dans Firefox, mais elle devrait également bientôt tourner dans tous les navigateurs supportant WebGL (Opéra, Chrome, Safari et peut-être même IE dans une dizaine d’années). Pour en savoir plus, n’hésitez pas à aller lire cet article de Vladimir Vukićević et l’annonce d’Epic Games.

La sortie d’Epic Citadel n’est pas qu’un épiphénomène, une démonstration de faisabilité, mais un symptôme parmi beaucoup d’autres de l’effervescence qui règne en ce moment dans le monde des jeux en HTML5. Pour preuve ces quelques autres actualités que j’ai vu passer ces derniers jours :

• pour encourager le développement de jeux en HTML, une catégorie dédiée a été créée sur MDN. Toute aide pour enrichir cette documentation et la traduire est évidemment la bienvenue ;

• Turbulenz vient de libérer sous licence MIT le moteur de jeux 2D et 3D qu’ils développent depuis plusieurs années. Le code, très complet, est sur Github ;

• Gamua est une société qui développe entre autre Starling et Sparrow, des moteurs 2D libres pour écrire respectivement des jeux Flash en ActionScript et iOS en Objective C. Ils ont annoncé une version Web de Starling, basée sur TypeScript (un sur-ensemble typé de JavaScript, impulsé par Microsoft) et WebGL. Elle partagera une API commune avec Starling et Sparrow, pour simplifier la création de jeux fonctionnant dans les trois environnements ;

• parmi les autres signes du déclin de Flash, Unity a annoncé il y a peu qu’ils cessaient le support de cette plate-forme ;

• les moteurs de jeu en HTML5 se multiplient, un site leur est désormais consacré, HTML5 Game Engine ;

• Microsoft a également bien compris l’importance des jeux pour promouvoir ses technologies. Voici par exemple un article de présentation de Phaser, autre moteur de jeu 2D en TypeScript et JavaScript ;

• et enfin si vous voulez des démos, voici les gagnants d’un concours de développement de jeux HTML5.

On célèbre ces jours-ci les vingt ans de la libération du Web. Quelques mois après cette libération, et sans aucun rapport, sortait Doom, qui ouvrait une nouvelle étape dans l’univers des jeux vidéos, en commençant à populariser les jeux multi-joueurs en 3D. Ce sont probablement deux des faits marquants de l’informatique en 1993. J’apprécie le clin d’œil de leur mariage vingt ans plus tard.

Dans le domaine techniquement pointu, HTML5 est peu à peu en train d’assoir sa crédibilité. De plus en plus d’outils sont disponibles. Ils vont permettre de créer des jeux qui tourneront sur tous nos écrans, ordinateurs, tablettes, téléphones, télévisions… Les outils sont là, reste à coder les jeux, et ça c’est votre boulot, alors hop ! Moi, je m’en vais réciter des mantras. Le Web est la plate-forme et Firefox (OS) son prophète. ad libitum

Un vendredi à l’heure de la sieste. Cinquante personnes entassées dans une salle pour assister à une réunion de service. Rituel des transparents qui défilent agrémentés d’images laules pour essayer de détourner l’attention de l’audience des ordiphones. Je n’ai pas d’ordiphone et m’emmerde tellement que j’en viens à suivre quelques minutes durant la présentation. Pour découvrir qu’elle contient nombre d’informations intéressantes, comme la mise à jour trimestrielle des noms internes des produits, titres des uns et des autres, etc. Le genre d’informations utiles au quotidien pour déchiffrer le jargon propre à la boîte et comprendre ce que disent mes petits camarades.

Hélas, toutes ces informations sont perdues. Enterrées dans pauvre point. Si je voulais les retrouver lundi, il me faudrait fouiller ma messagerie électronique ou les disques partagés pour récupérer le support de la présentation. Puis me battre pour ouvrir le .ppt. Y chercher l’information… Je ne le ferai jamais, et me demande d’ailleurs si quiconque a déjà ouvert un de ces documents envoyé à l’issue d’une présentation. C’est une des caractéristiques des documents PowerPoint. Écrits une fois, présentés une fois, jamais ré-ouvert. Quelle perte d’énergie, quelle perte d’information !

Ici, la forme (une présentation) va complètement à l’encontre de la diffusion pérenne de l’information. Pourtant cette forme n’est qu’une représentation de l’information. Quel dommage qu’en fait d’emballage Powerpoint crée des cercueils. Je suis de plus en plus partisan des chaînes éditoriales permettant simplement, à partir d’une information, d’en proposer plusieurs représentations. Par exemple, partir d’un fichier Markdown permet d’exporter le document en texte enrichi (pour l’envoyer par messagerie électronique), en HTML pour le mettre en ligne, et d’en faire une présentation avec des solutions comme S5 ou Slidy et apparentés. Un tel document peut être facilement consulté, réutilisé, indexé…

Pensez-y la prochaine fois que vous préparerez une présentation : est-ce que vous enfermerez les informations dans un format qui rendra leur réutilisation difficile, ou privilégierez-vous un format qui simplifiera leur diffusion ?

J’ai gazouillé plus tôt dans la journée que « Un des trucs dont l’Humanité a le plus besoin, c’est d’une normalisation d’un Markdown étendu, prenant en compte les annotations ». Cette forte pensée a suscité quelques réactions et comme 140 caractères sont un peu courts pour répondre, je vais développer ici. Markdown est mon langage de balisage favori, sans doute puisque, comme il s’inspire de conventions ancestrales pour la rédaction de mails, je le trouve assez intuitif.

Malheureusement, il lui manque quelques fonctionnalités pour couvrir l’essentiel de mes besoins, et en particulier une syntaxe pour des annotations ou des notes de pied de page dont je suis très friand. Et John Gruber ne semble pas décidé à faire évoluer la spécification originale qu’il a élaborée avec Aaron Swartz. De ce fait, de nombreuses propositions d’extension ont fleuri, comme par exemple MultiMarkdown et PHP Markdown Extra. Chacune de ces propositions a une implémentation de référence, et plusieurs outils proposent leur propres variantes, comme Maruku, Kramdown et bien entendu le couteau suisse Pandoc, l’outil quasi universel de conversion entre langages de balisages. Sans oublier bien sûr Github qui a également ses propres variations.

Les fonctionnalités proposées par les propositions d’extensions et les divers outils sont globalement les mêmes : notes de bas de page, tableaux, etc. Et les syntaxes similaires, mais avec d’infimes variations qui les rendent incompatibles entre elles. De fait, à moins de se limiter à la syntaxe de base, les documents écrits en Markdown ne sont pas interopérables. J’écris en ce moment cette note en Markdown et Maruku va la transformer en HTML. Mais rien ne me garantit que si demain je choisis un autre convertisseur, je ne vais pas perdre certaines informations, comme les notes de bas de page. C’est pourquoi il est urgent de se mettre d’accord sur une norme pour un Markdown v2 étendu. On pourra ainsi évaluer les différents outils existant à l’aune de leur respect de cette norme.

Le besoin d’une telle norme n’est pas récent, et en Octobre 2012 un groupe communautaire s’est créé au sein du W3C. Malheureusement, si j’en crois la liste de discussion publique, après une activité intense dans les premières semaines de son lancement, le groupe semble aujourd’hui en profonde hibernation (aucun message sur la liste publique depuis plusieurs mois). Sa principale production est un début de suite de tests, rédigés pas Karl. Vu l’engouement continu autour de Markdown depuis des années, je ne m’explique guère ce manque d’empressement à le standardiser. Et ne peut qu’espérer une prochaine standardisation d’une syntaxe pour les notes de pied de page, histoire de garantir l’interopérabilité de mes textes qui en font usage.

source : un échange avec Karl à propos des difficultés rencontrées par les développeurs d’Opquast Desktop.

J’entend régulièrement des plaintes à propos du système de revue des extensions de Firefox, et je crains que ses problèmes n’affectent demain l’épicerie d’applications Web promue par Mozilla. Je connais mal le problème, ce qui ne m’empêche pas d’avoir une opinion dessus.

Mozilla est une organisation à but non lucratif qui ne vend pas de produits. Ses ressources ne sont pas infinies, et toujours fragiles. Elle doit donc choisir la priorité de leur affectation afin de remplir au mieux sa mission, à savoir aider à faire d’internet un lieu convivial. Les extensions ont beaucoup contribué au succès de Firefox, mais ne sont plus aujourd’hui prioritaires. Ça ne signifie pas qu’elles ne sont plus importantes. Mais elles sont moins importantes que d’autres sujets au regard des objectifs actuels, à savoir garantir l’ouverture d’Internet dans l’univers mobile. Un peu comme Thunderbird en fait. Un beau projet, utile, nécessaire, mais plus au centre des préoccupations de la Fondation. Je partage le sentiment que trop se disperser empêche malheureusement d’avancer. Mozilla ne peut donc allouer à la revue des extensions les ressources nécessaires pour en faire un service qui satisfasse tout le monde.

Mais je dirais que peu importe. Si quelque chose n’existe pas, c’est qu’il y a une opportunité pour le créer. Et de même que je pense qu’il y a un marché économiquement viable pour maintenir Thunderbird (ce que font je crois plus ou moins quelques SSLL françaises), autant je pense qu’il y aurait de la place pour une plateforme de diffusion d’extensions et d’applications Web externe à Mozilla et économiquement viable. Ou du moins, il y aurait de la place si on arrêtait de mythifier la gratuité et si on disposait d’un système propre de micro-paiement.

Je défend la liberté entendue comme l’extension des droits des citoyens numériques. Je sais que cette liberté a un coût. Ce coût peut-être du temps. Ici cela signifie prendre le temps de me former puis pour chaque extension que je veux installer, analyser son code pour m’assurer qu’il ne pose pas de problème. Mais si je ne veux pas dépenser ce temps, ça ne me dérangerait pas de payer quelqu’un pour le faire à ma place (j’ai la chance d’avoir plus d’argent que de temps libre). Après tout, avant l’ADSL, j’achetais des revues informatiques pour récupérer des distribs GNU/Linux sur le CD joint plutôt que de passer mes nuits à les télécharger en 56ko. La gratuité est une conséquence non obligatoire de la liberté du code et de l’ouverture de l’organisation le produisant.

L’hébergement d’extensions par Mozilla a pour moi une vraie valeur ajoutée : je sais que les extensions que j’y trouve ne contiennent probablement pas de code volontairement ou non nuisible. J’attache de l’importance à cette tranquillité et serais près à verser quelques cents chaque fois que j’installe une extension pour payer le service. Mais à condition de disposer d’un système de paiement que me satisfasse (ie ou l’intermédiaire technique ne se goinfre pas de 30% de la transaction et qui ne permette à aucune des parties en présence de collecter des informations sur moi à partir de mes achats).

Le code source de l’épicerie d’applications développée par Mozilla est libre, c’est à dire que quiconque peut créer un site offrant un service de revue (ça n’est pas tout à fait vrai, toutes les places de marché ne pourront pour l’instant pas distribuer certaines applications critiques). Il suffit de trouver un moyen de financer ce service et surtout de gagner la confiance des utilisateurs et développeurs.

Je ne sais pas si une entreprise remplissant ces critères serait viable. Mais il y a à mon avis une voie à explorer. Plus de 3 milliards d’extensions ont déjà été téléchargées. Même en ne facturant que quelques cents par extension, cela représente une belle somme. Suffisante pour couvrir le coût le revue équivalent ? Aucune idée. Vos avis ?

En vrac, trois réflexions que l’annonce de la fermeture prochaine de Google Reader m’a inpiré.

Un — faire mieux au lieu de geindre

Les gens sont vraiment cons, ils mangent de la merde. En fait ils n’ont que ce qu’ils méritent, ils n’ont qu’à faire leurs courses au marché chez des petits producteurs régionaux, être dans une AMAP, faire la cuisine. Ce n’est quand même pas compliqué de bien manger !

Je fais partie de ces cons qui mangent de la merde. Parce qu’avoir une alimentation saine ne fait pas partie de mes priorités. Cela demande du temps et je préfère consacrer mon temps à des choses que j’estime plus importantes (comme lire Twitter, chacun ses choix). Aussi, je n’adhère plus au discours qui en réponse à la fermeture de Google Reader, appelle à installer sur son serveur un des nombreux lecteurs de flux libre. Arrêtons de penser en geeks. Moi même, tout geek que je sois, je n’installerai pas un clone de Google Reader sur un serveur, parce que j’essaie de réduire le temps que je passe à faire de l’administration système. Question de priorités.

Si nous voulons promouvoir ATOM et compagnie, ce n’est pas avec ce discours que nous y arriverons. Mais en fabriquant des produits au moins aussi bons, beaux, utiles, utilisables, que leurs alternatives privatives. Des logiciels qui seront choisis et utilisés parce qu’ils ne demandent pas d’efforts et améliorent la vie. Encore une fois, le succès de Firefox n’est pas dû à sa philosophie. Seule une petite minorité l’utilise parce qu’il est libre. Je suis persuadé que la grande majorité de ses utilisateurs l’ont choisi parce qu’il est objectivement meilleur, sur un plan ou un autre, que les autres navigateurs. Donc avant de blâmer ces crétins entre la chaise et le clavier qui deviennent prisonniers volontaires de services privateurs, blâmons nous de ne pas créer de logiciels meilleurs que leurs alternatives. Et, pour ceux d’entre-nous qui ne sont pas adeptes de l’auto-flagellation, sortez vous les pouces de la bouche, et au lieu de troller, créez !

Deux — savoir ce que l’on veut

Je n’ai jamais utilisé Google Reader. Je ne comprends donc pas son succès parmi les geeks et les infovores. Mais de quelques lectures et échanges depuis l’annonce de sa fermeture, j’ai l’impression que ce que ses veufs et veuves regretteront, ce n’est pas tant le lecteur RSS que le logiciel leur permettant de gérer de manière agréable une partie des contenus qu’ils consultent. Et que donc ce qui nous manque, ce n’est pas un nouvel agrégateur RSS, mais un bon système de gestion de contenus personnels. Par contenus personnels, j’entends tous les articles intéressants que nous voyons passer, en surfant ou qui nous arrivent directement via des flux, RSS, Twitter, les partages de marque-pages, etc. Mais aussi les discussions, sur des listes de courrier électronique, Twitter voire IRC. Tous ces articles que nous mettons de côté pour les lire un jour, que nous partageons, que parfois nous annotons ou commentons.

Aujourd’hui, tous ces contenus sont dispersés. Des dizaines de dossiers thématiques dans notre courrielleur, nos lecteurs de groupe de discussions et de flux RSS, des centaines d’onglets ouverts dans notre Firefox, divers gestionnaires de signets, des favoris dans Twitter, les journaux IRC, j’en oublie. Et pourtant, quel que soit le canal par lequel arrivent ces informations, elles sont globalement similaires. Des articles ou des conversations, des métas-données, et parfois des ajouts personnels, catégorisation et commentaires. Il me semblerait pertinent de les agréger dans un seul outil. Techniquement, ce n’est guère compliqué, et je pense qu’avec toutes les briques existantes, on pourrait facilement bricoler ce genre d’outil. Mais le succès de Google Reader me semble lié davantage à son ergonomie qu’à une supériorité technique. Et c’est sur ce point, l’utilisabilité, que se jouera la crédibilité des alternatives.

Le remplaçant du défunt lecteur de Google n’est donc peut-être pas à chercher du côté d’autres lecteurs de flux, mais de la création d’un gestionnaire de contenus personnels ergonomique. Qui archive tous les contenus que nous voyons passer, avec leurs méta-données. Qui nous permette d’y accéder de partout. En rende la lecture agréable. Le partage simple comme un clic. Et permette de les enrichir. Le tout doté d’une interface agréable à utiliser quelle que soit sa maîtrise de la chose informatique. Le navigateur de contenus de David est un pas dans cette direction.

Yaplukafokon

Trois — considération pratique

J’ai beau être conscient du danger des services en ligne comme Google Reader, je dois reconnaître qu’ils sont très pratiques et que leur trouver des alternatives accessibles et crédibles est difficile. Ils sont pratiques car ils offrent un service accessible de partout depuis un simple navigateur. Difficiles à concurrencer car, comme il n’est pas réaliste à court terme d’imaginer qu’une majorité d’internautes auto-héberge ses outils, concurrencer les services de Google et compagnie suppose pour l’instant de mettre en place une architecture technique similaire. C’est à dire une masse de serveurs pour traiter et stocker les données.

L’arrivée des applications Web va probablement modifier une partie du problème. Grâce à HTML5, on peut à présent créer des applications dont tous les traitements s’effectuent dans le navigateur. Les serveurs n’ont plus qu’à fournir des fichiers statiques, et gérer le stockage et la synchronisation des données. De plus en plus d’applications vont je pense adopter un modèle composé d’une applications HTML5 s’exécutant dans le navigateur, et d’une API serveur au dessus du modèle de données. La difficulté logistique à fournir un clone libre à Google Reader s’en trouve largement réduite. Reste la question du stockage des données.

J’ai proposé de détourner IMAP et d’utiliser les comptes mails que chacun possède comme entrepôts décentralisés de données, mais mon idée n’a guère suscité de réactions. Les Grands Génies sont rarement reconnus de leur vivant. Je reviens donc à la charge avec une autre proposition : inciter les FAI à soutenir le projet unhosted. L’idée de ce projet est de découpler le traitement des données de leur stockage. Ce qui permet d’utiliser un service hébergé tout en stockant ses données dans un autre dépôt, soit auto-hébergé, soit chez un prestataire. Il encourage donc entre autre la création de services proposant juste de l’hébergement de données. Ce sont de tels entrepôts dont les applications Web ouvertes ont besoin. Malheureusement, tout cela reste un peu trop technique, et je ne pense pas que les non-geeks soient prêts à trouver et payer un prestataire d’hébergement de données pour leurs applications. Il faudrait qu’un tel service leur soit fourni clé en main, avec leur connexion.

Or, la plupart des fournisseurs d’accès internet assortissent leur offre de services annexes, comme souvent une adresse de messagerie. Jadis, certains proposaient également l’hébergement de quelques pages Web, d’une site personnel. On pourrait imaginer que demain, quelques fournisseurs de qualité proposent, avec tout abonnement à Internet, un entrepôt en ligne où stocker les données de ses applications Web. Ainsi je pourrais partager sur mon compte FDN les données des applications s’exécutant dans mes Firefox.

Faire héberger nos données par notre FAI n’est bien sûr qu’à moitié satisfaisant. Et je doute que beaucoup de fournisseurs d’accès voient un quelconque intérêt à fournir ce service. L’idée ne me semble néanmoins pas complètement irréaliste.

À vous lire.

Une des premières réactions des gens à qui je montre Firefox OS via le simulateur est souvent… la déception. L’interface serait trop inspirée de celle des systèmes mobiles d’Apple ou de Google. Je ne sais pas si cette similitude d’interface est voulue, pour ne pas déboussoler les utilisateurs, ou la conséquence des délais très courts dans lesquels le produit a été conçu. Mais ces remarques m’inspirent deux réflexions.

La première est que nous attendons sans doute trop de Mozilla. Nous avons peut-être trop tendance à imaginer la fondation en révolutionnaire, quand elle n’est que réformiste (au sens respectable du terme). Son maître mot est le pragmatisme. Et, je dois le reconnaître, quoiqu’il m’en coûte, c’est une des principales raisons de son succès : préférer les évolutions douces et le pragmatisme à l’utopie révolutionnaire. C’est la raison par exemple de son choix dès le début d’HTML 5, simple évolution d’HTML 4, plutôt que de la rupture annoncée par XHTML 2 et XForm. Bien sûr, la fondation sait nous faire rêver. Il y a quelques années, ses laboratoires sortaient tous les mois de nouveaux prototypes très innovants, qui faisaient saliver. Mais tous ou presque ont été rapidement abandonnés, au profit d’une évolution continue et en douceur de Firefox. Firefox OS lui-même n’est pas révolutionnaire, bien d’autres avant avaient déjà eu l’idée d’un OS Web. Mais c’est parce que le projet est géré de manière très pragmatique, en essayant d’arriver le plus vite possible sur le marché avec juste les fonctionnalités minimales pour être viable, en se concentrant sur les attentes des utilisateurs, c’est pour cela qu’il a des chances de réussir et de produire un changement profond et durable.

La seconde réflexion est que nous n’avons peut-être pas encore découvert un des intérêts (pour les geeks) de Firefox OS. C’est probablement la maquette de système d’exploitation la plus simple à modifier. On l’a dit et répété, l’ensemble de l’interface utilisateur, l’ensemble des interactions, sont entièrement réalisées en HTML / CSS / JavaScript. Ça en fait donc un terrain de jeu plutôt accessible pour les concepteurs d’interaction qui veulent essayer de nouveaux paradigmes. Vous avez des idées en matière de design, d’ergonomie, de manière d’interagir avec les utilisateurs ? Il suffit pour les tester de connaître les technos du Web, ou d’avoir sous la main quelqu’un qui les connait. La mise à jour de Gaïa, l’interface de Firefox OS, est vraiment des plus simples, pratiquement aussi simple que jouer en direct avec la maquette d’un site Web. C’est une magnifique plate-forme pour imaginer de nouvelles formes d’interactions au niveau, non uniquement d’une application, mais d’un système entier. Et j’espère que des concepteurs vont s’en emparer pour proposer d’autres façons d’utiliser un téléphone.

Parmi les différentes expériences que j’ai en ce moment sur le feu pour apprendre à développer des applications Web, un petit machin tout simple de prise de notes. Une fois réglé la question du stockage local, je me suis dit qu’il serait pratique, lorsque j’aurai un terminal mobile, de pouvoir récupérer sur ma machine principale les notes saisies dans les transports. Renseignement pris, il n’existe pas encore d’API de synchronisation dans Firefox OS, et ça ne semble pas une priorité, le premier marché visé étant les pays émergents et non les geeks qui jonglent entre plusieurs terminaux. Je réfléchis donc depuis quelques jours à une solution de synchronisation.

L’apprenti geek en moi jouerait bien avec CouchDB, une base de données qui incorpore nativement des fonctionnalités avancées de synchronisation. Mais cela signifierait en avoir une instance sur un serveur et donc devoir administrer sur le long terme ce service. Or je ne veux plus rajouter de trucs sur mon serveur. Surtout, c’est une solution qui réserverait mon application aux boutonneux et boutonneuses dans mon genre, capable d’installer un serveur. Une solution accessible à tout internaute me plairait davantage, surtout si elle évite le piège de dépendre d’un entrepôt central.

Le problème de la synchronisation est qu’à moins de le faire directement entre deux terminaux (bientôt possible avec WebRTC ?), elle demande de passer par une passerelle, et que celle-ci constitue souvent un point de centralisation. Le meilleur exemple est sans doute Google. Pour y remédier, il faudrait que les internautes puissent facilement disposer de leur propre instance de serveur de synchronisation. Je me souviens de projets pour installer facilement des paquets de logiciels, dont le serveur Sync de Mozilla. Mais je crois qu’ils ne sont malheureusement jamais sortis du cercle des boutonneux.

À vrai dire, si l’on cherche un service largement répandu chez des internautes non technophiles, réellement décentralisé, encadré par des spécifications, et qui permet à chacun et chacune de lire et d’écrire des données, je ne vois qu’un seul candidat : la messagerie (éventuellement la messagerie instantanée, à présent que XMPP a pratiquement tout unifié).

Pourquoi ne pas donc utiliser un compte mail comme serveur de synchronisation ? Ou du moins de stockage de données partagées entre plusieurs instances d’une application. L’idée n’est pas neuve, GmailFs par exemple permettait d’utiliser un compte Gmail comme espace de stockage. Tout ce dont l’utilisateur aurait besoin pour synchroniser ses différents terminaux serait une adresse mail.

Si l’idée est simple, la réalisation risque de l’être nettement moins. Pour en arriver là, il faudrait :

• définir un protocole de communication avec le serveur de messagerie. Ce protocole devrait offrir plusieurs méthodes de connexion. Si le serveur est accessible en IMAP ou POP3 et que l’application a accès à de vrais sockets (comme la TCP Socket API présente dans Firefox OS), les échanges ne poseront pas de problèmes. Sinon, il faudra soit envisager des passerelles (un service Web gérant les échanges IMAP), mais qui réintroduisent un point de passage obligé, soit des connecteurs pour que l’application navigue sur les Webmails et simule une connexion IMAP (sur le modèle par exemple de DavMAIL qui crée un vrai serveur POP/IMAP/SMTP au dessus du Webmail d’Exchange) ;
• définir un format de stockage des données, et gérer les diverses limitations des services (taille des messages, recherche plus ou moins aisée, etc) ;
• trouver des algorithmes performants de synchronisation, qui minimisent les échanges réseau. C’est sans doute la partie la plus simple, de telles fonctionnalités étant déjà présentes dans de nombreux logiciels libres ;
• on peut aussi imaginer un répertoire listant les connecteurs disponibles en fonction de l’adresse de l’utilisateur, et les installant à la demande. Par exemple un utilisateur de FirefoxOS utilisant une adresse GMail pourrait utiliser un connecteur IMAP natif, quand le possesseur d’une adresse hotmail devrait passer par une surcouche du Webmail (le tout de manière évidemment transparente).

J’ai cette idée en tête depuis quelques jours, et sa mise en œuvre est très largement au dessus de mes compétences et de mes disponibilités. J’en jette donc le brouillon ici pour voir ce qu’elle vous inspire.

(Merci à Nicolas B. Pierron et Goofy pour les relectures)

asm.js est un projet de recherche de Mozilla qui vise à améliorer les performances de JavaScript en n’utilisant qu’un sous-ensemble du langage, plus facile à optimiser.

Il se compose de plusieurs sous-projets :

• la spécification du langage ;
• OdinMonkey, un module de l’interpréteur JavaScript SpiderMonkey, qui prend en charge le code asm.js ;
• des travaux sur emscripten pour que le code généré soit conforme à la spécification asm.js ;

Asm.js

La spécification ne conserve qu’un sous-ensemble strict d’EcmaScript, respectant certaines règles. Ce n’est donc pas, à la différence de CoffeeScript ou TypeScript par exemple, un nouveau langage. Le code asm.js est du JavaScript valide qui peut s’exécuter dans tous les navigateurs récents.

Parmi les exemples d’optimisation, asm.js s’assure que les variables ne changent pas de type. Le code inclut des indications sur le type des variables, afin que l’interpréteur n’ait pas à le deviner. Le langage permet également une meilleure utilisation de la mémoire, limitant les ralentissements causés par le garbage collector (le code asm.js utilise des tableaux typés (_typed arrays_) comme pile pour certaines opérations).

Pour indiquer à l’interpréteur JS que le code respecte la spécification et peut être optimisé, il suffit d’ajouter une nouvelle directive "use asm" de syntaxe similaire au "use strict". Si l’interpréteur ne reconnait pas cette directive, il l’ignorera et interprètera le code normalement. Sinon, il validera que le code respecte bien la norme, et si oui, l’exécutera de façon optimisée.

OdinMonkey

OdinMonkey va bientôt être intégré au tronc de SpiderMonkey. Les performances semblent intéressantes, puisque du code C++ compilé via Emscripten puis interprété par OdinMonkey ne s’exécute que deux fois plus lentement que lorsqu’il est compilé avec gcc. Ce sont des performances similaires à celles de langages utilisant une machine virtuelle, comme Java ou C#.

Emscripten

Emscripten est un compilateur qui traduit en JavaScript du bytecode LLVM obtenu à partir de source en C ou C++. Il permet donc de porter des programmes écrits en C ou C++ pour les exécuter dans un interpréteur JavaScript. À titre d’exemple, un portage de la bibliothèque de composants graphiques multi-plateformes Qt est en cours, qui permet d’exécuter des applications « natives » écrites pour Qt dans un navigateur, la balise canvas étant utilisée pour l’affichage. Pour tester les possibilités d’asm.js en matière de jeux, un portage du jeu de tir en vue subjective Cube 2: Sauerbraten a été entrepris.

D’autres expériences visent à porter les interpréteurs de divers langages. Repl.it propose d’exécuter directement dans le navigateur, après conversion en JavaScript, des programmes écrits en Ruby, Python, Lua, Scheme…

L’assembleur du Web

Plus que les implications en terme de performance, l’intérêt d’asm.js est qu’il permet de faire un pas de plus vers le Web comme plate-forme applicative, dont les navigateurs seront le système d’exploitation. D’ici quelques années, il sera possible de faire fonctionner n’importe quel code, quel que soit le langage dans lequel il a été écrit, dans un navigateur.

Bien sûr, il faut raison garder. Il n’y a pas grand-chose de neuf sous le soleil. Le portage d’applications natives vers le navigateur est une vieille lune. Java promettait cela il y a 15 ans, avec le succès que l’on sait. GWT permet depuis des années de compiler d’autres langages en JS, et je n’ai pas l’impression qu’il soit très utilisé hors de Google. Je ne crois guère que des applications entières seront portées directement en JS. Mais je pense que cela va accroitre la perméabilité entre les environnements frontend et backend. Avec SpiderMonkey et node, du code JS écrit pour le navigateur pouvait s’exécuter sur le serveur. Bientôt, toute bibliothèque “serveur” pourra s’exécuter dans le navigateur. On pourra ainsi réellement partager du code, l’écrire dans son langage de prédilection et l’exécuter selon le contexte dans le navigateur ou sur un serveur.

Quelques liens

• une présentation d’Alon Zakai, chercheur de Mozilla et un des trois pères d’asm.js ;
• asm.js: closing the gap between JavaScript and native par le toujours complet Dr. Axel Rauschmayer ;
• asm.js: A Low Level, Highly Optimizable Subset of JavaScript for Compilers.

Karl nous incitait récemment à renforcer le caractère hypermédia de nos publications sur le Web en utilisant notamment l’attribut rel qui permet de qualifier un lien.

David disait hier à peu près qu’un souci avec nos carnets est que le mécanisme actuel de commentaires sous les billets transforme ce qui devrait être une énorme fourmilière parsemée de couloirs en maisons individuelles isolées..

Actuellement, je vois essentiellement l’attribut rel utilisé pour gérer la pagination à l’intérieur des carnets. Indiquer aux robots (moteurs de recherche ou fonctionnalité d’aide à la navigation dans le navigateur) les premiers et derniers billets, le précédent et le suivant. Mais ce ne sont pas forcément les liens les plus pertinents sur une page. Lorsque je lis le billet de David, m’intéresse davantage le contexte que la liste des autres publications sur d’autres sujets dans son carnet. Un robot devrait pouvoir détecter à qui répond ce billet, quelles sont les autres réponses, et les billets qui eux-même y répondent (feu nos trackbacks). Il suffirait que l’auteur ajoute manuellement ces références à son article. On pourrait ainsi extraire une carte affichant le billet dans son contexte, une visualisation de la conversation.

Malheureusement, je n’ai pas trouvé de valeur de rel signifiant « répond à », « complète » ou « a suscité cette réaction ». De telles relations existent dans certains vocabulaires (par exemple references et isReferencedBy en Dublin Core) mais cela nécessite probablement d’utiliser RDFa Lite ou les micro-données HTML5, donc une chaîne de publication plus lourde. À moins que… Le Dublin Core a proposé d’utiliser son vocabulaire dans des rel (ce que je fais d’ailleurs ici-bas), mais ça ne semble pas normalisée. La syntaxe serait <a rel="dct:references">…</a> (pour autant que la proposition concerne aussi les balises A et non uniquement les LINK).

Mais puisque la discussion sur le sujet des commentaires reprend, pourquoi ne pas réfléchir à pousser à la normalisation de la proposition du DC, ou à proposer de nouvelles valeurs pour rel ?

Note personnelle : ce carnet est actuellement rédigé en Markdown et converti en HTML avec Maruku. Maruku implémente une extension de Markdown qui permet d’ajouter des attributs aux éléments :

This is [a link][ref]{:#myid rel=abc rev=abc}

Je pourrais donc rajouter les attributs rel directement dans mon Markdown. Mais malheureusement je crois que Maruku est le seul interpréteur Markdown à implémenter cette extension, cela lierait donc mes billets à un logiciel (et les enfermerait dans un format non standard).

Je me demande si j’aime la direction dans laquelle va le Web.

Je me suis récemment amusé à une de mes vieilles marottes, ajouter de la sémantique sur ce site. L’occasion de constater une fois de plus l’état navrant du Web Sémantique :

• il y a actuellement deux spécifications qui font pratiquement la même chose, RDFa Lite et les micro-données HTML5. Aucune ne semble prendre le dessus, il faut donc si on veut être exhaustif ajouter au code les attributs des deux (et des micro-formats pour faire bonne mesure). C’est peu lisible (cf la bouillie du code source de cette page)) et encore moins maintenable ;
• bien peu d’outils existent, comme le souligne Karl, pour ne serait-ce que valider le code. Ne parlons même pas de consommer ces méta-données ;

Bien sûr, en cherchant et tâtonnant un peu, on y arrive, mais c’est laborieux, et il faut vraiment comme moi préférer affûter ses outils que s’en servir pour se donner la peine d’ajouter ces informations sémantiques.

On est en 2013, et le Web Sémantique reste toujours un rêve de chercheurs et un joujou pour geeks snobinards. Pratiquement rien n’a changé depuis que j’ai commencé à m’y intéresser il y huit ans. Quelle différence avec le chemin parcouru par le Web Applicatif. Jadis, deux visions du Web se sont affrontées. XHTML 2 vs HTML5. Le Web des données contre le Web des applications. Ceux qui voulaient que la toile SOIT une gigantesque base de toutes les connaissances que l’on pourrait interroger contre ceux qui voulaient l’utiliser comme fondation pour FAIRE. Être et faire, toujours. Le résultat est connu depuis longtemps, les pragmatiques l’ont emporté.

J’ai toujours eu le cul entre deux chaises. Je préfère savoir plutôt que faire, suis persuadé que le savoir est la condition sine qua non de l’action. Pratique excuse à mon immobilisme. Les promesses du Web des données me faisaient donc rêver. Construire une cathédrale dédiée au savoir. Mais je m’intéresse aussi à la liberté, et à tout ce qui nous donne les moyens concrets d’être plus libre, plus autonome. Et le Web des applications constitue de ce point de vue une formidable opportunité. Internet et le Web sont une des plate-formes les plus ouvertes qui soit. Les outils bâtis au-dessus embarquent par défaut cette ouverture dans leur ADN (ça n’est bien sûr pas une garantie, les contre-exemples sont légions, mais l’ouverture est une possibilité native). J’ai donc soutenu avec enthousiasme la croissance de ce Web, et l’arrivée de FirefoxOS est une étape très importante dans l’histoire du Web Applicatif, une chance de prouver que le pari original était le bon, que le Web est une plate-forme applicative sérieuse. Mais une étape c’est aussi l’occasion de faire une pause et de regarder dans le rétroviseur. Et de constater que cette évolution s’est aussi faite au détriment de mon cher Web Sémantique.

Le constat de cet échec à se concrétiser des promesses du Web Sémantique donne un goût un peu amer à la victoire en cours du Web Applicatif. Samedi prochain, je tâcherai de passer à l’App Day parisien. Mais, hormis fêter FirefoxOS, je me demande ce que j’y ferai. Après tout, je ne suis pas un menuisier numérique, juste un petit écrivaillon qui rêve de cathédrales.