IE9 supportera le SVG

La nouvelle vient de tomber : IE9 commencera à implémenter le SVG.
La preview qui a été présentée il y a quelques heures gère environ 30% de la spécification (les parties les plus simples).

La route est longue avant d’avoir le support des fonctionnalités les plus puissantes, comme les filtres ou l’animation déclarative, mais cela reste une très bonne nouvelle pour SVG qui devient le standard pour les graphismes vectoriels sur le web.

De plus, il semble que IE9 gèrera le type mime application/xhtml+xml. On pourra donc vraiment travailler en XML et en plus, SVGround deviendra accessible aux utilisateurs d’IE.

Longue vie à SVG !

Posted in , | Leave a comment

L'architecture XRX : la fin du développement web douloureux

Dans cet article, je vais présenter une nouvelle architecture de développement web, répondant au petit nom de XRX. Si le titre définit cette architecture par une opposition (au développement web actuel), c’est parceque je n’ai pas trouvé l’adjectif adéquat. Passionnante, exaltante, géniale cette architecture ? Surement, mais ça ne sonne pas bien. Pourtant, cette architecture simple et élégante comme la décrivent certains, révolutionne vraiment la manière actuelle de faire. En bien mieux.

Le développement web aujourd’hui

Ayant eu le malheur de me replonger il y a peu dans du développement web, j’ai eu l’occasion de me rendre compte en quoi il est absolument cassé et pénible.

Sur le client, on utilise le couple XHtml/CSS dont il faut reconnaître qu’il remplit correctement le rôle qui est le sien : structurer et présenter l’information. Seulement, ce n’est pas assez pour le développement d’applications. On ne peut pas blâmer XHtml pour ça, ça n’a jamais été son rôle. Le problème, c’est qu’on est quand même obligé de s’en servir !

C’est la que débarque la cavalerie : AJAX. AJAX, qui n’a rien de révolutionnaire, est le concept qui prône l’utilisation massive de Javascript et de l’objet XMLHttpRequest sur le client. Et en effet, avec des tonnes de Javascript il devient possible de créer des sites se rapprochant d’applications, moyennant des performances moyennes mais surtout une complexité effrayante même pour faire des choses basiques.

Regardons de plus prêt l’objet XMLHttpRequest. Si il a eu un tel succès, c’est parcequ’il permet de recharger une partie de la page sans recharger l’essemble de la page. Waouh. Je suis d’accord avec ceux qui me diront que ça permet d’économiser des resources, même si je ne suis pas sûr que ce soit vital dans la majorité des cas. Mais regardons les defauts de cette méthode : c’est d’une complexité incroyable ! Le scripts Javascript (avec ou sans AJAX d’ailleurs) sont imbuvables. N’espérez pas qu’ils soient facilement maintenables, c’est très difficile dès le moment où vous commencer à utiliser de l’AJAX. Si vous devez vous replonger dedans, ça sera la croix et la bannière pour comprendre le code. À la clef, une énorme perte de temps et des maux de têtes.

Voici comment on a perdu toute la simplicité et la légèreté du HTML.

En définitive, faire de l’AJAX, c’est refaire le travail du navigateur (envoyer la requête HTTP et traiter son retour) à la main. Pour une architecture moderne et bien pensée, on repassera. Si quelqu’un a déjà pris du plaisir à faire de l’AJAX, qu’il me fasse signe. Il apparait donc que cette technique est une béquille en attendant mieux. Comme le note Laurent Jouanneau, Ajax est déjà obsolète.

Une petite digression en passant. J’ai eu le malheur de devoir faire du Flex. Flex, pour ce qui ne connaissent pas, c’est le langage d’Adobe pour faire des applications web, choisi par beaucoup de responsables intoxiqués par la publicité d’Adobe (l’argument étant qu’ »on peut faire de jolies interfaces »). Quelle fut ma surprise quand j’ai réalisé que Flex se base sur de l’Ajax, en le simplifiant à peine. Ainsi, on doit toujours construire soit même ses requêtes HTTP, les envoyer et traiter le résultat de la requête. Même si le framework simplifie certains aspects de l’Ajax (on peut utiliser directement le XML résultant de la requête HTTP dans les composants de l’interface utilisateur), ça n’innove pas vraiment sur ce front. C’est pourquoi je suis plutôt sceptique sur l’avenir à long terme de ce langage. Si on peut éviter un web binaire et dirigé par une seule entreprise, tant mieux.

Cet aspect des choses n’est qu’une partie de ce qui constitue le développement web. Pour l’autre partie, ça se passe côté serveur.

Du côté du serveur, on utilise dans la majorité des cas un langage middleware, comme PHP, ASP ou Java et un système de gestion de base de données relationnelles (ici, chaque terme a son importance), dont le plus célèbre est sans doute MySQL.

Le rôle du middleware, prenons PHP par exemple, est la traduction. PHP récupère les différents paramètres issus de d’un requête HTTP (GET et POST dans la plupart des cas). Grâce à ces paramètres, on va former une requête SQL. Puis on exécute la requête. Si elle renvoie un résultat (SELECT), on le traite, et dans tous les cas, on recrache du code HTML qu’on renvoie au navigateur.

Le gros problème ne se situe pas du côté de PHP, mais du côté du système de gestion de base de données. Les bases de données qu’on utilise travaillent avec données tabulaires. Ça pose un énorme problème dans la mesure ou vos données ne sont quasiment jamais tabulaires. Et c’est là que commencent vos ennuis. Il faut plusieurs tables. Pour que vos données restent cohérentes, il faut utiliser des clefs étrangères afin de dire que telle cellule fait référence à une ligne d’une autre table. Ainsi, dès que la complexité de votre modèle de données augmente, il faut multiplier les tables et les contraintes qui vont avec. Mais en même temps, cela va complexifier vos requêtes. Vous aurez à multiplier les jointures externes. Et je ne parle même pas de l’insertion de données dans de telles structures, puisqu’il faut potentiellement ajouter des données dans plusieurs tables. Et si vous n’avez pas bien exprimé les contraintes entre les différentes tables, vous allez vite vous retrouver avec des données orphelines. Si le concept de bases de données épaisses essaye d’éviter cela, cela ne change rien au problème fondamental, qui est que ces multiples transformations apportent de la complexité et, potentiellement, des erreurs.

Sur le web, vos données ne sont pas tabulaires. Elles sont arborescentes.

L’architecture XRX

XRX tient pour XForms, Rest et XQuery.

Cette architecture simplifie le développement web dans le sens où on ne traite que du XML :

  • XML sur le client ;
  • XML sur le serveur ;
  • des interfaces REST entre les deux.

Plus précisément, on utilise

  • XForms sur le client,
  • des interfaces REST et
  • XQuery sur le serveur.

Grâce à cette architecture, plus besoin de transformer les données pour les faire tenir dans des structures tabulaires dans une base de données : toute la chaine utilise XML.

Sur le client, XForms

XForms est un langage conçu pour remplacer les formulaires web. Ils sont cependant très différents de ces derniers puisque ce langage s’appuie sur une architecture MVC (modèle, vue, contrôleur).

Ainsi, les données et les éléments de contrôle (bouton, champ de texte, liste déroulante, etc) ne sont pas mélangés.

Le modèle XForms contient à la fois les données récoltées (au format XML) et vouées à être envoyées au serveur, les contraintes qui s’exercent sur ces données (types, pertinence, donnée requise et autres contraintes) et les différentes manières dont elles peuvent être soumises. Les données peuvent être soumises directement en XML ou de manière plus classique avec les requêtes HTTP POST et GET habituelles.

Répétons-le : ces données et les contrôles sont complètement séparés.

Une des fonctionnalités clefs de XForms, c’est la vie après la soumission de ses données. En effet, on peut choisir d’afficher la nouvelle page, de ne rien faire, ou de remplacer tout ou partie du modèle XML par les données reçues en réponse. Il devient donc possible de recharger une partie de la page sans la recharger complètement. En un mot, faire de l’AJAX, à ceci près que c’est beaucoup plus simple puisqu’à la place de lourds scripts javascript, il n’y a besoin que de quelques éléments XForms.

Notons qu’il est aussi possible de précharger les données du modèle de manière à ce que le formulaire soit préremplit.

Au niveau des contrôles, on trouve tous ceux présent dans HTML, plus une commande d’étendue (<range/>) et une commande de sortie (<output/>) qui permet d’afficher une donnée du modèle XML. De plus, l’apparence des contrôles est intimement liée au type de la donnée auquel il est rattaché. Par exemple, si le contrôle est lié à une donné de type date, un calendrier s’affichera à la place d’un zone de texte. De même, si la donnée et de type booléen, c’est une case à cocher qui s’affichera. Les contrôles étant liés aux données, ils sont modifiés lorsque les données auxquelles ils sont rattachés sont modifiés. Ainsi, si plusieurs élément de contrôle sont liés à la même donnée, ils auront toujours le même état.

XForms gère aussi les structures répétitives. On peut donc construire des tableaux ou des listes à partir des données du modèle, insérer ou supprimer un élément, modifier les données d’une répétition, etc.

Les contrôleurs permettent d’établir des contraintes sur les données et les contrôles qui leurs sont associées. Ainsi, on peut définir le type d’une donnée conformément à XML Schéma, décider qu’une donnée est en lecture seule, requise, ou inutile (et dans ce dernier cas les contrôles qui sont liés à une telle données ne sont pas affichés) selon l’état d’autres données du modèle, on peut aussi calculer une valeur (par exemple une moyenne), et bien plus. On peut appliquer des styles CSS selon les différents cas. Par exemple, les contrôles en lecture seule peuvent avoir un fond grisé.

On peut également séparer le formulaire en différentes sections qui s’afficheront au fur et à mesure et à certaines conditions.

Enfin, il est possible de réagir à divers évènements (et toujours de façon déclarative, donc sans avoir recours à des scripts) : lorsque le chargement est terminé, lorsque les données sont sur le point d’être envoyées, lorsque les données sont en cours de soumission, lorsque les données sont reçues, lorsqu’on active un élément de contrôle, lorsqu’on insère ou supprime un élément dans une structure répétitive, lors de la sélection dans une liste, lorsqu’une erreur survient (ressource distante inexistante, erreur lors de la soumission, etc), etc. Il est en suite possible de répondre à ces évènements, en affichant un message d’erreur, en insérant ou en supprimant un élément dans une structure répétitive, en affectant une valeur à une donnée, en affectant le focus à un élément particulier, en affichant une partie précise du formulaire et ainsi de suite.

Tout ceci est possible sans écrire une seule ligne de javascript.

XForms utilise XPath, XML Schema et CSS tous les trois promus par le W3C.

Le principal défaut de XForms est qu’il n’est pas implémenté directement dans les navigateurs, et dans un avenir proche ce ne sera pas le cas, les développeurs privilégiant Webforms2, une évolution des formulaires Html. Malheureusement Webforms2 est conçu dans le but de ne pas casser la compatibilité et même s’il reprend certains concepts de XForms, il n’est pas assez puissant pour intégrer l’architecture XRX. Il faut donc se rabattre sur des bibliothèques capables de simuler XForms. Côté client, on pourra citer la bibliothèque javascript multi-navigateur Ubiquity Xforms qui semble le projet le plus prometteur à l’heure actuelle.

Sur le serveur, XQuery

L’essence de l’architecture XRX, c’est de n’avoir aucune transformations des données. Grâce à XForms, cela devient possible. En effet, les données d’un formulaire XForms sont au format XML. Il est en outre possible d’envoyer ces données directement en XML. Donc, côté serveur, il suffit de stocker ce fichier XML grâce à une base de donnée XML. Ainsi, les données ne sont pas transformées. Au contraire, elles sont rigoureusement les mêmes sur le client et sur le serveur.

On manipule les données d’une base de données XML grâce à XQuery. XQuery est le SQL du XML. Il est aussi puissant que SQL, mais permet de manipuler des données arborescente (XML) ce qui évidemment beaucoup plus puissant. XQuery est un langage fonctionnel sans effet de bord (qui ne modifie pas les données) mais des extensions standards intoduisent la mise à jour des données XML. XQuery n’est pas plus compliqué que SQL. Au contraire, étant donné qu’on utilise des structures arborescentes, les besoins en jointures se font plus rares.

Mais le mieux avec XQuery, c’est que ce langage renvoie directement du XML, et donc potentiellement du XHtml, du SVG et du XForms. Ainsi, une étape traditionnelle de transformation saute. Le résultat de la requête est directement renvoyée au navigateur dans des formats qu’il connait. En fait, XQuery est très intuitif et ne déroutera pas ceux qui ont déjà travaillé avec les bases de données traditionnelles.

XQuery peut aussi renvoyer des fichiers XML « bruts » à un formulaire XForms. Dans le cas où on veut remplacer AJAX, on renvoie seulement les donées nécessaires au formulaire XForms pour pouvoir continuer. Par exemple, lorsqu’on sélectionne une catégorie dans un formulaire XForms, celui-ci peut demander au serveur la liste des sous-catégories qui lui sera renvoyée en XML afin que le formulaire se mette à jour sans recharger toute la page.

Puisque vous semblez bruler d’envie de voir à quoi ressemble XQuery, voici une très brève introduction. Les requêtes XQuery sont constuires à partir d’expressions FLOWR, composées des instructions for, let, where, order by et result. L’instruction for permet de traiter une liste de nœuds. L’instruction let permet d’affecter une valeur à une variable qui, puisqu’on est dans un langage fonctionnel, n’est pas modifiable par la suite. L’instruction where permet de filtrer une liste de nœud, mais on peut aussi utiliser des prédicat. En plus, WHERE permet d’effectuer les jointures. La clause ORDER BY, comme sont nom l’indique, ordonne le résultat. Enfin, l’instruction RETURN renvoie un valeur ou un document XML.

Voici par exemple comment on renvoie une page XHtml simple à partir de données stockées dans une base de données XML :

<html> <head />
<body>
<h1>Liste des discussions</h1>
<ul>
{ for $discussion in document('discussions.xml')//discussion return
<li><a href="showDiscussion.xq?discussionsId={$discussion/@id}">{$discussion/titre}</a></li> }
</ul> }
</body>
</html>

avec un fichier discussion ayant un structure ressemblant à :

<discussions>
<discussion id="1">
<titre>Blabla</titre>
<texte>
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nam consequat nisi in risus volutpat nec sollicitudin justo pharetra. Class aptent taciti sociosqu ad litora torquent per conubia nostra, per inceptos himenaeos. Pellentesque mi urna, dapibus et elementum et, tristique sit amet justo. Nulla convallis orci et eros condimentum fringilla. Suspendisse nec nisl felis, eu eleifend erat. Vivamus et urna nec nisi sollicitudin lacinia. Nullam ipsum purus, vehicula a faucibus eget, lobortis in justo. Aenean eget tempor nunc. Duis elit massa, rutrum a dignissim id, facilisis a leo. Proin felis est, cursus a ultrices eu, commodo ut ante.
</texte>
</discussion>
<discussion id="2">
<titre>Bla bla bla</titre>
<texte>
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nam consequat nisi in risus volutpat nec sollicitudin justo pharetra. Class aptent taciti sociosqu ad litora torquent per conubia nostra, per inceptos himenaeos. Pellentesque mi urna, dapibus et elementum et, tristique sit amet justo. Nulla convallis orci et eros condimentum fringilla. Suspendisse nec nisl felis, eu eleifend erat. Vivamus et urna nec nisi sollicitudin lacinia. Nullam ipsum purus, vehicula a faucibus eget, lobortis in justo. Aenean eget tempor nunc. Duis elit massa, rutrum a dignissim id, facilisis a leo. Proin felis est, cursus a ultrices eu, commodo ut ante.
</texte>
</discussion>
</discussions>

Il est bien sûr possible de récupérer les paramètres et les données envoyés par la requête HTTP (GET, POST, PUT, DELETE). De même, rappelez vous qu’on peut renvoyer n’importe quel document XML, pas forcément une page XHtml.

XQuery, comme XForms, utilise le langage d’adressage XPath, très intuitif. XPath, en plus de pouvoir désigner certaines parties d’un document, peut effectuer des opérations sur les nombres, les chaînes de caractères, les dates et les nœuds XML. D’ailleurs, on peut souvent remplacer la clause WHERE par des prédicats XPath. XQuery utilise XPath2, plus puissant que sont prédécesseur XPath1.0. XForms2 utilisera aussi XPath2.

L’exemple précédent est simple, mais sachez qu’on peut imbriquer plusieurs niveaux de requêtes XQuery et donc produire des pages d’une complexité arbitraire.

Coté implémentation, c’est mieux que XForms. La majorité des bases de données importantes supportent la norme. En plus de cela, il existe une base de données XML libre, eXist. Elle gère très bien XQuery et apporte les extensions indispensables à l’architecture XRX. Ainsi on peut facilement récupérer les données issues de http, on peut utiliser un mécanisme d’authentification à la UNIX, on peut utiliser XInclude et Xslt, on peut utiliser WebDav et il y a même un module de traitement d’image. En prime, cette base de données XML semble à première vue plutôt performante (son créateur est très impliqué dans la norme XQuery) malgré qu’elle soit en Java (ce qui implique tout de même que eXist est portable). Ainsi, il devient possible de se passer complètement de langage tiers comme PHP ou ASP.

J’allais oublier : on peut aussi valider coté serveur les données reçues au format XML avec un schéma. On peut donc utiliser le même schéma XML sur le serveur et sur le client.

Entre les deux : des interfaces REST

La communication entre le navigateur et la base de données se fait via des interfaces REST, donc des URI.

Dans cette architecture, il est important de bien connaitre les subtilités d’HTTP. En effet, avec les bases de données XML, on utilise souvent des collections de documents XML stockés dans des dossiers. Grâce aux requêtes HTTP de type PUT et DELETE, il devient extrêmement facile de remplacer ou de supprimer un document XML faisant parti d’une collection, à condition de bien gérer les droits d’accès.

Ce qui devient intéressant, c’est qu’avec XRX on peut publier un service Web très facilement. En fait, chaque script XQuery devient un service Web.

Conclusion

XRX apporte ce qui manque au développement web : la simplicité. Quand on voit tous les framework qui sont nés et qui naissent encore des lacunes du développement web traditionnel, toutes ces usines à gaz, il est évident qu’il y a besoin de quelque chose de plus simple. XRX, en réduisant grandement la complexité et la quantité de code (division par 10 diront certains) des applications Web, répond à ce besoin.

Pour aller plus loin :

Posted in , , | Leave a comment

Nouveau chapitre XForms : modèle

Tout est dans le titre, je suis productif en ce moment et vous pouvez dès à présent lire le premier vrai chapitre : les modèles.

Posted in , | Leave a comment

Un client Jabber en XUL

Il est une idée qui me trotte dans la tête depuis approximativement un an, et il est temps que je la jette sur le papier. Cette idée, c’est la réalisation d’un client Jabber sur la plateforme Mozilla. Quand j’y pense, je suis étonné des possibilités énormes qu’offrirait un tel logiciel.

Genèse

Á l’origine, j’avais pour idée de développer un logiciel d’édition SVG collaboratif sur la plateforme Mozilla. Xulrunner est installé sur des millions de pc grâce à Firefox. SVG progressant plutôt vite dans Gecko, j’avais imaginé une extension aux salles de conférences Jabber pour l’édition de document XML. Au delà des problèmes intéressants de synchronisation que cela pose (et qui ont déjà été discuté, voire les archives des listes de discussion XMPP), ce logiciel aurait aussi permit d’autres choses intéressantes.

La première aurait été de pouvoir faire des présentations sur le Web, à la Powerpoint. SVG permet de faire des présentations de très bonne qualité, sans compter que la version1.2 de ce langage inclura surement des effets de transitions (entre les pages), l’élément <page/>, le son et la vidéo et d’autres fonctionnalités qui feront de SVG un langage qui permet de faire autant de chose que les lourds logiciels de présentation (Powerpoint, Impress) dans un format Web. Pour passer d’une diapo à l’autre, il suffirait de changer des attributs CSS (visibility:hidden ou visibility:visible). Mais l’élément <page/> du futur SVG1.2 se comporte comme un élément d’animation et il aurait suffit de pouvoir, grâce à une commande XMPP, lancer une animation comme on le fait avec la méthode du DOM SVG beginElement().

Cette idée en apporta une autre : il aurait tout aussi bien été possible de réaliser des jeux de plateau ou des jeux de rôle grâce à cette infrastructure. SVG serait utilisé pour les graphismes et XMPP pour modifier les données SVG. Mieux : en utilisant Javascript pour traiter le flux XMPP, on a accès à des possibilités beaucoup plus étendues.

Prenons par exemple un jeu d’échec (pour faire simple). Il est très facile d’étendre le protocole XMPP pour y inclure son balisage spécifique. Avec la découverte des services, on peut facilement savoir si le contact d’en face peut gérer ce balisage. Une fois la partie commencée, l’interface graphique envoie les mouvements des pièces à l’adversaire :

<message from='moi@jeudechec.net'
 to='lui@sonfournisseur.com'>
 <chess xmlns="http://jeudechec.net/chessns" type="move" from="D4" to="E6"/>
 </message>
 

Et voilà que mon cavalier se déplace en E6.

Du côté de mon adversaire, ce message est traité et une animation est lancée sur son graphique SVG.

Ce système à un inconvénient, c’est qu’il est facile de tricher. Chaque client peut vérifier la cohérence des mouvements des pièces ou alors on peut faire appel à un script côté serveur.

Á ce stade, les possibilités de la plateforme sont déjà sympatiques.

Une extension parmi d’autres

L’idée fit son cheminement jusqu’à arriver à la conclusion suivante : de telles applications (édition SVG collaborative, jeux, etc) ne pourraient finalement qu’être des extensions parmi d’autres dans une plateforme beaucoup plus générique.

Cette plateforme beaucoup plus générique serait un client Jabber basé sur la plateforme Mozilla. Bref, un Firefox de la messagerie instantanée, tout simplement.

Car ce qui a en partie fait le succès de Firefox, ce sont sa légèreté, les possibilités offertes par sa plateforme et ses extensions faciles à créer et à déployer. Et c’est transposable à un client Jabber en XUL.

L’architecture

Á vrai dire, j’ai réalisé un prototype fonctionnel de cette idée un jour de grève générale. Oui, en un jour : c’est la rapidité de développement qu’on peut atteindre avec la la plateforme Mozilla basée sur Xulrunner. Voici une caputre d’écran de ce prototype :

Capture décran de Papaya, prototype dun client Jabber en XUL

Capture d'écran de Papaya, prototype d'un client Jabber en XUL

Papaya, son petit nom, permet déjà d’afficher la liste des contacts, d’envoyer et de recevoir des messages et de changer sa présence (avec le message qui va avec). Bien sûr, c’est codé à la va vite et le code n’est pas montrable.

Ce qui est important est la manière dont je l’ai réalisé.

Pour la partie Jabber (protocole XMPP), je me suis basé sur la bibliothèque XMPP4Moz qui s’installe comme une extension. Elle gère le protocole de base : presence, message, chat, erreurs. Elle est pratique : on peut désigner des fonctions de callback lors de la réception d’une réponse. De plus, contrairement à certaines bibliothèques Javascript pour XMPP, elle se connecte en TCP grâce aux composants réseaux de la plateforme Mozilla. Les bibliothèques javascript se content de faire du pull ou du push sur HTTP.

Le programme entier est une application Xulrunner. Sous Unix, il suffit de taper

xulrunner application.ini

et le tour est joué. Si Xulrunner n’est pas installé, alors on peut faire :

firefox -app aplication.ini

Pour débugger, vous connaissez sans doute la console d’erreur de Firefox. On peut avoir la même pour développer des applications XUL :

xulrunner application.ini -jsconsole

La gestion du style se fait très classiquement avec CSS. Pour la localisation, on utilise un système basé sur les DTD, très simple.

Le plus, c’est la manière dont XMPP4Moz traite le XML. Ici point de DOM, trop lourd, on utilise à la place E4X qui permet de manipuler du XML directement en javascript. Par exemple :

var message = <message from='expediteur@exemple.net'
 to='destinataire@exemple.com'
 xml:lang='fr'>
 <body>{messageText}</body>
 </message>;
 

E4X est parfaitement adapté à la manipulation de fragments de XML qu’on traite avec le protocole XMPP.

Enfin, grâce à l’utilisation d’XBL, les extensions pourront facilement étendre les fonctionnalités.

Les projets existants

Il existe plusieurs projets de client XUL à l’heure actuel.

Le premier est Sameplace, qui est basé sur XMPP4Moz. Sameplace est une extension de Firefox qui permet d’avoir de la messagerie isntantanée dans le navigateur. C’est une très bonne idée dans la mesure où cela rend possible les interactions avec les pages web visités au même moment. Mais à mon avis, un navigateur est déjà assez lourd pour ne pas y inclure en plus un client de messagerie instantané. Essayez, et vous verrez qu’il vous manquera rapidement de la place.

Instantbird est un client standalone en XUL basé sur la célèbre libpurple qui motorise Pidgin et Adium. Ce client est multiprotocole et c’est à mon avis là son principal défaut : gérer plusieurs protocoles qui n’ont pas les mêmes possibilités ralentit le développement et brident les possibilités. Et puis de toute façon, XMPP, comme SMTP à son époque, finira par s’imposer. Pourquoi alors perdre du temps avec les autres protocoles ? (Oui, je sais, ce point est discutable, mais je ne suis pas sûr que développer pour les autres réseaux propriétaires fera migrer d’une quelconque manière les utilisateurs vers Jabber.) Il reste que c’est un logiciel de qualité et la lecture de son code m’a beaucoup appris.

La dernière tentative est un client XUL dans le navigateur du nom de OneTeam, développé par Process One, la boîte à l’origine d’Ejabberd. Encore une fois, le fait que cela se passe dans le navigateur est je pense une mauvaise idée. Bien que tout se fait sur le « Web 2.0″ aujourd’hui, je pense qu’un client standalone a encore sa place sur les bureaux des utilisateurs, qui utilisent bien MSN ou un autre client de messagerie instantanée.

J’aimerais pour ma part tenter cette voix du client standalone.

Les possibilités d’une telle plateforme

Un tel logiciel serait très facilement extensible grâce au gestionnaire d’extension intégré de Xulrunner. Rappelez vous, j’ai intégré XMPP4Moz de cette manière ;) Voici une liste des choses qu’il serait possible d’implémenter via des extensions :

  • édition collaborative de documents XML à deux ou plus grâce aux salles de discussion : XHtml, SVG, XForms, XSL-FO (si c’est implémenté un jour) ;
  • extensions sociales à la Facebook, sans la centralisation dangereuse qui va avec ;
  • partage de fichier et basé sur ça pourquoi pas un Darknet : je partage mes fichiers et les fichiers de mes amis et ceux des amis de mes amis ;
  • publication avec Pubsub : humeur, ce que j’écoute, activité, photos, etc ;
  • extension des salles de conférences, de n’importe quelle manière ;
  • grâce à Jingle, il devient possible de gérer les flux de pair à pair ;
  • conférence audio et/ou vidéo à plusieurs dans une salle de discussion. En même temps, par exemple, qu’une présentation SVG ;
  • ou pendant un jeu ;
  • grâce à Jingle (vitesse de transfert élevée et latence faible), on peut imaginer l’utilisation de Canvas pour réaliser des applications (par exemple des jeux) temps réel. Quand Canvas3D sera implémenté, il sera possible de réaliser des applications 3D temps réel ;
  • des extensions pourraient proposer des services comme des passerelles téléphoniques ;
  • toutes sortes de robots côté serveur pourraient communiquer avec des extensions. Exemple : un jeu de poker en ligne (en SVG, Canvas ou Canvas3d pour les graphismes) ;
  • etc

Pour résumer, on pourrait utiliser toute la plateforme Mozilla en temps réels et en mode de collaboration avec sa liste de contact. Le champ des possible devient vaste, autant pour les particuliers que pour les entreprises. Pour ces dernières, il serait possible de construire une suite collaborative complète (audio, vidéo, partage de documents via une pubsub, édition simultanée, etc).

Les difficultés

La principale difficulté de ce projet serait, comme pour beaucoup de client Jabber, l’implémentation de Jingle. Sauf que Xulrunner n’est pas une plateforme multimédia. Je vois ici plusieurs solutions.

La première est d’utiliser ce qui est déjà inclut dans la plateforme, à savoir les formats Theora, Vorbis et Speex. Ce dernier codec sera très probablement inclut très bientôt et ça tombe bien puisqu’il est très utilisé pour la Voip. Reste à savoir s’il est facile d’utiliser ce qui existe déjà dans un cadre où le flux est du véritable streaming. Sans compter que l’inclusion de codecs supplémentaires risque d’être plus difficile…

La seconde solution serait d’utiliser des bibliothèques tierces, et je dois dire que le projet Telepathy qui est le projet de messagerie XMPP de Gnome (pour faire simple) est plutôt attirant. En plus d’un moteur XMPP (qui pourrait  remplacer XMPP4Moz), elle intègre tout ce qu’il faut pour établir des connections avec Jingle.  Google a aussi sorti une bibliothèque pour ça, libjingle.

La grande question est de savoir si la plateforme est assez robuste pour gérer des flux vidéos et audios…

Voilà où j’en suis pour le moment. Le temps me manque pour commencer un tel projet mais j’en ai parlé autour de moi (et je continue de le faire) et les retours sont positifs, voire très positifs.

Posted in , | Leave a comment

XForms : introduction

Je viens de commencer le tutoriel XForms et vous pouvez dès à présent lire l’introduction.

Toute remarque est bienvenue.

Posted in , | Leave a comment

Futur du support SVG

Le support du SVG est très disparate selon les navigateurs.

Il y a d’abord le très bon élève, Opera, qui supporte notamment l’animation déclarative et les fontes SVG. Sinon, le support est quasiment parfait et le seul problème avec ce navigateur est que le processus de rapport de bug n’est pas ouvert (en gros, on envoie un mail sans jamais recevoir la moindre réponse).

Il y a ensuite les deux moteurs qui montent : Gecko (Firefox) et Webkit (Safari, Google Chrome). Un gros travail est actuellement fait pour que Gecko supporte enfin l’animation déclarative et le code est déjà inclus dans le tronc. Les prochaines releases auront donc un support basique des animations déclaratives mais pas complet. Pour l’instant il n’y a pas de support pour la synchronisation d’animations (machin démarre quand truc se termine). Pour Webkit, les progrès sont plus rapides. SMIL est aussi en train d’être implémenté et ça avance plutôt rapidement, même si l’impression que j’en ai est que la qualité finale de l’implémentation est moins bonne que dans Gecko. En tout cas, le point positif est que les filtres sont quasiment implémentés dans ces trois moteurs de rendu (en y incluant Presto, le moteur d’Opera).

Internet Explorer, par contre, ne supporte pas du tout SVG. Et s’appuyer sur le plugin d’Adobe, abandonné, serait une erreur. La question qui se pose est donc : quid de la prochaine version d’Internet Explorer, IE9 ?

D’un côté, SVG est une norme complexe et longue à implémenter. Étant donné le travail que l’équipe dIE doit déjà effectuer sur leur moteur de rendu, il semble difficile de croire que SVG soit implémenté en 2011, date probable de sortie d’IE9. En plus, SVG rentre en concurrence frontale avec Silverlight, le langage à tout faire de Microsoft. Implémenter SVG serait aller contre la stratégie du géant qui vise à imposer ses standards grâce à son poids et à ses parts de marchés sur l’OS et le navigateur.

D’un autre côté, Silverlight a du mal à percer et la place est déjà prise par Adobe Flex (qui finira bien par mourir). Tous les autres navigateurs offriront, en 2011, un support très bon de SVG. La question est : IE peut il rester le seul à ne pas l’implémenter ? En tout cas, Google tient absolument à utiliser SVG et veut pousser IE à l’implémenter. Google utilise déjà ce langage dans ses produits, comme Google Maps ou Google Docs. Le SVG est traduit en VML pour Internet Explorer.

La prochaine conférence SVGOpen qui se déroulera en Octobre prochain sera l’occasion pour Google de présenter SVGWeb, un moteur javascript capable de convertir du code SVG en VML pour Internet Explorer. La stratégie semble claire : si vous n’implémentez pas SVG, nous le ferons, avec les problèmes de performances qu’une utilisation massive de Javascript implique. Si Microsoft veut arrêter de perdre des parts des marchés, il a donc intérêt à implémenter SVG…

Microsoft nous a habitué aux coups tordus. Si IE9 implémente SVG, il faudra encore voir quelle est la qualité de ce support. Avec sa stratégie embrace, extend, extinguish, on peut redouter le pire surtout que Microsoft utilise toujours cette stratégiecomme on l’a vu réccemment avec leur implémentation d’ODF.

Le chemin est donc encore long avant de pouvoir faire du SVG sans se soucier du support, la meilleur solution pour le moment étant encore de ne pas développer pour Internet Explorer, quand c’est possible.

Posted in | Leave a comment

Cours SVG presque terminé

Cela fait plusieurs années que j’ai débuté SVGround. C’était l’époque où seul Internet Explorer et le plugin d’Adobe donnaient un rendu acceptable. Les choses ont bien changé depuis !

Ce fameux plugin n’est plus supporté et comme prévu, l’avenir du SVG est d’être intégré au navigateur. Les progrès de Gecko, Presto et Webkit sont rapides et promettent de belles choses pour le futur.

En tout cas, le cours SVG est quasiment terminé et je ne travaillerais plus dessus avant un petit moment. Il reste toutefois quelques parties à écrire. J’en fais ici la liste :

  • polices SVG
  • primitive d’éclairage pour les filtres
  • primitive feDisplacementMap, quand j’arriverais à obtenir ce que je veux ce qui n’est pas le cas pour le moment
  • DOM SVG et élément <use/> (implémentations buggées ou inexistantes pour le moment)
  • image SVG dans du CSS, feature qui ouvre un large éventail de possibilités
  • si cette fonctionnalité prend le chemin de la standardisation, filtres SVG pour contenu html
  • propriété CSS fill-rule
  • zoom centré avec currentTranslate et currentScale (je n’y suis pas arrivé pour le moment)
  • coordonnées de la souris sur le dessin SVG (idem que précédemment, la viewbox, preserveAspectRatio, currentScale et currentTranslate rentrent en compte)
  • relecture et correction (pfff)

En plus de cela il faudrait que j’intègre un colorateur syntaxique javascript qui se marie bien avec la structure de SVGround. C’est malheureusement moins évident que ça en à l’air.

Mais pour l’instant, j’ai envie de m’attaquer à un nouveau cours traitant de XForms. Tous ceux qui font du dev Web savent à quel point… c’est en fin de compte chiant et répétitif. XForms est une des pierres angulaires de l’architecture de développement Web XRX qui rend à elle toute seule Javascript (et donc Ajax), PHP et SQL obsolètes.

Le plan est donc le suivant : attirer sur SVGround les développeurs qui seront de plus en plus amenés à développer en SVG et leur faire découvrir XForms et XRX.

Bien sûr l’écriture d’un cours demande beaucoup de temps, à l’image du cours SVG que j’ai mis plusieurs années à terminer. Il faut en plus trouver la motivation de travailler sur des langages quasiment inutilisés (je dois avoir le goût des standards non implémentés). Il n’y a pas très longtemps, l’avenir de SVG n’apparaissait pas aussi sûr qu’aujourd’hui…

Vous pourrez suivre l’avancement du cours XForms ici ou sur le MUC xmpp:svgfr@chat.jabberfr.org

Posted in , , | Leave a comment