Visions pour Jabber
Dans un de mes posts sur le forum de JabberFr.org, je raconte, du point de vue d'un geek/nerd, mes tests très sommaires et fais part de mes reflexions sur les clients Jabber sous Windows (oui, je l'ai dit, très sommaire, je n'ai pas eu le temps de tester les clients Linux et Mac OS X).
Je considère suite à ces tests, notammant après avoir utilisé l'excellent mais malheureusement défunt Gush, que les actuels clients d'IM (par extension maintenant de VoIP) sont pour moi la future-ancienne façon de concevoir un client d'IM/VoIP.
Du fait de l'intégration de l'archivage de messages, je m'imaginais un logiciel à l'interface d'un client e-mail. Dans ce cas, pourquoi ne pas intégrer Jabber/XMPP dans un PIM comme Kontact, Evolution ou Lightning ? La gestion de contacts serait donc centralisée et l'IM/VoIP pourrait bénéficier également de l'historisation et la recherche du PIM. Mais celà devenait trop complexe à gérer au niveau IHM, du fait de la nature intrinsèquement différente de la messagerie traditionnelle, instantanée et de la voix, comme on le voit dans la suite du fil de discussion du forum.
L'alternative d'un logiciel à tout faire est d'éclater toutes les fonctions utilisateur (les parties IHM) et d'enfouir le client (la partie technique) dans le bureau. Après avoir lu un peu, je vois bien évidemment comme tout le monde son intégration comme fonctionnalité de base du bureau : tout plein de trucs dans les boutonsd, barres, fonds d'écrans et autres fenêtres système, et des clics droits partout, y compris dans les applications qui n'ont rien à voir a priori comme la bureautique.
Robert Quattlebaum explique sa vision technique d'un démon tournant sur le poste. Ce démon est client Jabber. Les applications (IM, VoIP, whiteboard, etc.) font appel à ce démon. Ainsi, pas besoin de multiplier le paysage déjà surchargé de clients Jabber, on concentre les efforts des différentes communautés de développeurs sur le travail applicatif et l'IHM, ou sur la partie enfouie (API) pour les plus sioux.
Jean-Louis Seguineau juge l'idée intéressante, mais souligne que ce n'est que déplacer le développement de l'espace client vers l'espace application. Il ajoute que les API enfouies dans les plateformes pour les éditeurs tiers sont le vrai nerf de la guerre.
Quoiqu'il en soit, Ubuntu/Kubuntu et Freedesktop travaillent sur l'idée : leur but est de fournir une plateforme basée sur D-Bus qui unifie toute forme de communication en temps-réel, incluant la messagerie instantanée, l'IRC, la voix et la visioconférence, en fournissant une interface simple aux applications clientes leur permettant de rapidement d'utiliser des communications temps-réel sur totu type de protocole supporté.
Pour l'instant, ce sont des visions du futur de Jabber, le travail étant en cours. Nous verrons ce qu'il adviendra…
En tout cas la vision d'un bureau intégrant à part entière Jabber comme un acquis par défaut est une bonne chose, d'une part car la messagerie instantanée et la VoIP deviennent omniprésents et d'autre part car le morcellement et la fragmentation extrême dont souffre ce domaine n'ont d'équivalent dans aucun autre domaine.
Sir Mespompes 08:27 le 2006-05-27 Permalien |
L’idée de présenter un client jabber comme un client email n’est, comme tu le dis, pas bonne. Les plus anciens jabberistes se rappelleront d’ailleurs que le premier client jabber, WinJab, ancètre d’Exodus, était sous cette forme. C’était d’une laideur/ergonomie repoussante.
Pour moi aussi la séparation core/GUI des clients jabber est la voie à suivre, d’ailleurs on peut remarquer que l’équipe qui développe Gaim souhaite en faire de meme avec son client. Ca permettrait de concentrer les efforts sur un core commun et de permettre son utilisation depuis des interfaces en GTK, Qt, ou meme console, et aux développeurs de ces dernières de se concentrer dessus et d’avancer plus vite. Ca permettrait en fait meme à n’importe quelle application d’utiliser le reseau jabber sans avoir à intégrer elle-meme la gestion de ce protocol.
C’est d’ailleurs la philosophie d’Unix que de batir des applications en utilisant des briques logicielles, où tout doit etre réutilisable. Comme cdrecord qui est utilisé par des dizaines d’interfaces graphiques de gravure de cd.
Mais sous Windows où la tendance a toujours été de grosses applications à tout faire, j’ai peur que cette vision ai du mal à s’imposer un jour.