Vu sur le blog de Seesmic la possibilité de suivre par un bot Jabber des évènements sur des contenus ou des utilisateurs. Le bot permet de tracker du texte ou des vidéos de la même manière que le bot Jabber de Twitter.

Même si Jabber / Gtalk n’est pas encore l’IM le plus usité sur le Net il n’en reste pas moins que c’est celui le plus implémenté grâce au standard ouvert qu’est XMPP. Sachant que les messageries instantanées sont au moins, sinon plus, autant employées qu’un navigateur web je pense que l’implémentation de quelques XEP tel que la XEP-0071: XHTML-IM qui permet d’envoyer au client du texte riche au format XHTML, comme le fait Gajim, pourrait aider à populariser Jabber. Les wallpapers animés dans le texte c’est le minimum syndical il parait

Pour faire suite à mon billet sur les lapins, voici un article très intéressant, Got applications?, de Peter Saint-Andre le directeur de la XMPP Standards Foundation. Je conseille en complément la lecture rapide de ses slides à l’eComm.

En effet même si XMPP est de plus en plus utilisé en backend, HTTP via REST est toujours autant populaire pour fournir des APIs publics. Cependant, à moins de s’appeler Google ou Amazon et d’avoir suffisamment de ressources en matériels et bande passante à gaspiller, ce protocole synchrone nécessitant des poolings n’est pas du tout adapté comme il l’explique avec l’exemple de Twitter.
Le problème de Twitter n’est pas Rails. Leur problème est de proposer un service ayant de plus en plus de succès, utilisé par de plus en plus d’applications tierces et traitant une somme considérable de données à chaque seconde. De la même manière, on ne peut pas dire que Facebook soit très rapide.
Or pour résoudre ces problèmes de tenue en charge, HTTP n’est pas le meilleur candidat… Il n’est pas concu pour maintenir une connexion client serveur ou serveur serveur, à moins de bricoler, et n’est pas concu pour conserver un état entre chaque requête, à moins de bricoler. Bref on se gausse du web2, mais c’est une vaste blague face à l’énergie dépensé en développement et en administration pour compenser ses lacunes, afin de s’approcher, de loin, de ce qui ce fait depuis des décennies et simplement sur le desktop. Certes le navigateur web est universel, quoi que là encore l’énergie dépensé pour faire fonctionner et présenter correctement un site sur tous les navigateurs est phénoménale.

Bien sûr HTTP n’est pas prêt de disparaître en tant que protocole navigateur web serveur. La question se pose, serveur à serveur et client desktop à serveur comme le propose Peter Saint-Andre. Il est plus simple de convaincre des développeurs, surtout si on obtient ainsi un lapin plus réactif

Non cela ne résoud toujours pas le problème entre le navigateur et le serveur. Mais qui peut croire qu’un service à succès est utilisé plusieurs fois par heure depuis un navigateur ?! L’utilisateur le veut à porté de doigt en permanence, intégré à son desktop ou à son iPhone et surtout qu’il consomme le moins de ressources possible. En sommes tout le contraire d’un navigateur …

L’avenir du développement des architectures web se dirige clairement vers des environnements asynchrones et concurrentiels. Bref des outils adaptés aux besoins. Laissons HTTP à ce qu’il sait faire : servir des pages.

On connait tous XMPP le protocole utilisé par Jabber, comme service de messagerie instantané que nous souhaiterions voir se démocratiser un peu plus.

Cependant il serait très réducteur de limiter ce protocole à un usage sur le frontend. En effet ce protocole est idéal pour permettre à des applications backend de communiquer entre elles, et ce de manière asynchrone.

J’avais écris un article à ce sujet, détaillant une implémentation de ce système avec Ruby on Rails (De la répartition de charge en Ruby on Rails).

Je viens de découvrir que certains lapins ont décidé de parler en XMPP Le fameux nabaztag.

Pour résumer mes recherches, il s’avère que ce robot est constamment connecté aux serveurs de l’éditeur afin de récupérer des données (mails, sons, mises à jour, …). Or il utilisait un bon vieux pooling moisi. On imagine bien que ce fonctionnement a fini par saturer les serveurs d’autant plus que le problème est proprotionnel au nombre de nabaztag dans la nature. Ceci explique les problèmes de latences insupportables, voir d’indisponibilités observées par les clients furieux, voir aussi nabaztag-review.

Au début de cette année, la société Violet a donc modifié son backend afin d’utiliser Jabber, ou plutôt XMPP et les XEPs. Le site propose de tester cette version béta. Plus de détails de la “jabbérisation” ici beta-test-les-tagtags-sous-jabber et ici nabaztag bullet.

Violet a donc pu améliorer la qualité de son service en n’invoquant plus des pools mais des pushs serveurs -> clients, comme je le déduis.

XMPP suit donc son petit bonhomme de chemin, et il est à parier qu’il sera de plus en plus utilisé dans les backend, même si évidement les communications à ce sujet sont rare, mais on peut citer TiVo : XMPP in TiVo

La leçon à tirer est qu’il me parait vital pour une entreprise qui décide de fournir un service de qualité à ses utilisateurs, de prendre le temps de penser correctement son architecture dès la conception, d’autant plus lorsqu’on vise le grand public.
La deuxième leçon est que XMPP est l’outil idéal pour répondre aux critères de scalabilité et standards ouverts. Cependant je pense que le protocole ne fait pas tout et qu’il est nécessaire d’utiliser des outils et langages de développement adaptés à ce type d’architecture tel que Erlang mais cela fera peut être l’objet d’un futur billet.

Pour finir avec le nabaztag, je préfère de loin l’équivalent complètement libre et ouvert du tuxdroid, qui même s’il ne propose pas pour l’instant toutes les fonctionnalités du lapin ne peut que le surpasser à long terme.

Je viens de publier un article en 2 parties sur le blog d’AF83 :

De la répartition de charge en Ruby on Rails 1/2

De la répartition de charge en Ruby on Rails 2/2

C’est plutôt technique, et présente une solution parmi tant d’autres dans ce domaine très particulier.