Comme je l'ai déjà dit dans un précédent journal
http://linuxfr.org/~tiennou_minet/20258.html
je vois Jabber/XMPP comme un successeur de SMTP et un bon moyen de communication pour construire des communautés. Je me suis donc interrogé sur ce qu'il manque aujourd'hui à Jabber pour atteindre ces buts. Un des éléments qui m'est apparu est l'absence d'un système de listes de diffusion (similaire aux mailing-lists).
Certains pourront soutenir que les communications de groupe sont déjà prises en compte par les salons de discussion mais l'approche n'est pas du tout le même. La différence entre une liste de diffusion Jabber et un salon de discussion Jabber est la même qu'entre une mailing-list SMTP et un salon IRC. Il n'y a pas grand chose que vous pourriez faire avec l'un et pas avec l'autre mais on ne les utilise pourtant pas de la même façon. Ces outils sont plutôt complémentaires.
J'ai donc programmé le composant PyListC (Python List Component) dont la deuxième version de test sort aujourd'hui :
http://jabberstudio.org/projects/pylistc/project/view.php
Le composant s'utilise côté serveur comme n'importe quel autre composant (passerelle, serveur de discussion, etc.). Pour créer une liste, il suffit de remplir un petit formulaire en indiquant l'action à effectuer (ici "créer" donc) et le nom de la liste à créer. Pour s'inscrire à une liste, il suffit d'ajouter un contact du type NOM_DE_LA_LISTE@NOM_DU_COMPOSANT. Pour poster un message, il suffit d'envoyer un message à ce contact.
Un des avantages de faire un système de listes de diffusion sur un système de messagerie instantanée est de pouvoir prendre en compte l'état de présence des utilisateurs. Ainsi, il est possible de diffuser un message à tous les utilisateurs (comme pour l'e-mail) ou bien seulement aux utilisateurs en ligne. A vous d'évaluer la pertinence du message à long terme.
Je voudrais savoir quels types d'usages vous sembleraient intéressants pour un tel composant. Quelles fonctionnalités voudriez-vous voir ajoutées ?
Pour ceux qui disposent d'un compte Jabber sur un serveur public, ils peuvent essayer le composant sur le serveur libreasso.net. Le JID (adresse Jabber) du composant est list.libreasso.net.
Si le composant ne marche pas, réessayez un peu plus tard car il a été arrêté quelques temps à cause d'un gros bug.
La page du projet sur jabberstudio :
http://jabberstudio.org/projects/pylistc/project/view.php
Le site du projet avec la documentation :
http://pylistc.jabberstudio.org/
Journal PyListC : la messagerie instantanée a maintenant son système de diffusion
13
déc.
2005
# PubSub
Posté par davux (site web personnel) . Évalué à 2.
De manière générale, reproduire à l'identique les fonctionnalités/usages de SMTP est clairement une bonne idée (c'est d'ailleurs l'un des objectifs de Peter Saint-Andre depuis quelque temps, me semble-t-il).
Cependant, je pense que reproduire à l'identique l'implémentation n'est pas forcément nécessaire. À la place, il pourrait être intéressant d'exploiter les outils qui font la plus-value de Jabber. Dans le cas particulier des listes de diffusion, utiliser PubSub serait peut-être une bonne idée, si ce n'est pas déjà le cas.
Mes 2 centimes d'euro.
[^] # Re: PubSub
Posté par tiennou_minet . Évalué à 3.
C'est ce que j'ai commencé à faire mais je me suis vite aperçu que les implantations existantes de pubsub restaient encore assez limitées. De plus, d'un point de vue technique, il s'est avéré finalement plus compliqué de faire un composant interface que de gérer moi-même les listes. J'ai donc fait marche arrière et décidé de faire un composant autonome.
En fait, mon composant est plus une preuve de concept. Si l'idée intéresse du monde et qu'il commence à être déployé plus largement, il sera certainement préférable d'écrire une JEP décrivant le format d'une liste de diffusion pour utiliser l'architecture de pubsub existante et pour que les clients puissent développer des interfaces mieux adaptées aux listes de diffusion. A ce moment là, l'idée du composant interface prendra certainement tout son sens pour faire la transition.
Le fait que le composant soit autonome permet de tester facilement et rapidement cette fonctionnalité mais il est vrai que ce n'est pas la meilleure solution à long terme.
# Le volume ?
Posté par Adrien Bourdet . Évalué à 1.
Pendant combien de temps (et quelle taille) les messages sont-ils stockés sur le serveur quand l'utilisateur est déconnecté ?
Concernant les fonctionnalités/idées :
- Existe-t-il un moyen d'obtenir une hiérarchie des messages d'une discussion ?
- L'inclusion de formattage pour inclure des extraits de codes sources est-elle prévue ?
oui je sais, la "contrainte" est qu'il ne faut pas obliger l'utilisateur à avoir un client jabber particulier, mais vu que jabber est "extensible"... :p
[^] # Re: Le volume ?
Posté par tiennou_minet . Évalué à 2.
C'est l'intéret de faire une liste par messagerie instantanée plutôt que par e-mail. Par défaut les messages ne sont envoyés qu'aux utilisateurs en ligne (donc tu ne reçois jamais rien si tu es déconnecté car parti en vacances).
Mon composant relaie les messages, ce n'est pas lui qui gère la durée de stockage sur le serveur.
Au niveau des principaux serveurs Jabber, je crois que les limitations qu'on peut imposer portent uniquement sur une valeur maximale de l'espace de stockage, pas sur une date d'expiration des messages. En tout cas, c'est un paramètre qui ne dépend que de l'implantation et de la configuration du serveur utilisé (comme pour le mail). On peut très bien imaginer qu'un utilisateur utilise une interface web pour paramétrer son compte Jabber en précisant de ne pas garder les messages de plus d'une semaine par exemple.
Ceci dit, il existe une extension (JEP) permettant de spécifier la durée de validité d'un message :
http://www.jabber.org/jeps/jep-0079.html
Si un client spécifie que le message ne doit pas être distribué après une semaine et que ton serveur supporte ce JEP, tu ne recevras pas le message en question en te connectant deux semaines plus tard. En utilisant ce principe, c'est l'émetteur du message qui évalue la pertinence de son message à long terme mais cette valeur pourrait très bien être changée par PyListC.
La norme prévoit un élément <thread /> permettant d'identifier un fil de discussion. Par contre, à ma connaissance on ne peut pas spécifier précisemment à quel message du fil de discussion on répond (un seul niveau de hiérarchie donc). J'imagine qu'une extension sera définie quand le besoin s'en fera sentir.
Idem, ce n'est pas mon composant qui s'occupe de ça, il ne fait que relayer les messages.
Avec Jabber, on peut envoyer du texte formaté :
http://www.jabber.org/jeps/jep-0071.html
Cette norme, inspirée du XHTML, prévoit en effet un attribut <code /> qui s'utilise comme l'élément du même nom en XHTML.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.