Journal PyListC : la messagerie instantanée a maintenant son système de diffusion

Posté par .
Tags : aucun
0
13
déc.
2005
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/
  • # PubSub

    Posté par (page perso) . Évalué à 2.

    Après avoir lu rapidement la présentation du projet, je n'ai pas vu de mention de pubsub. Est-ce que PyListC l'utilise ?

    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 . Évalué à 3.

      Effectivement ma première idée a été d'utiliser pubsub et de simplement faire un composant "interface" pour que n'importe quel client puisse l'utiliser sans avoir à implanter la fonctionnalité de listes de diffusion en question.

      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 . Évalué à 1.

    Le problème de certaines listes de diffusions est amha le volume de mail généré par jour. Par exemple la très réactivle liste de diffusion d'entre-aide pour OOo a innondé ma boîte alors que j'étais parti une semaine.
    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 . Évalué à 2.

      Le problème de certaines listes de diffusions est amha le volume de mail généré par jour. Par exemple la très réactivle liste de diffusion d'entre-aide pour OOo a innondé ma boîte alors que j'étais parti une semaine.


      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).

      Pendant combien de temps (et quelle taille) les messages sont-ils stockés sur le serveur quand l'utilisateur est déconnecté ?


      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.

      Existe-t-il un moyen d'obtenir une hiérarchie des messages d'une discussion ?


      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.

      L'inclusion de formattage pour inclure des extraits de codes sources est-elle prévue ?


      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 à ceux qui les ont postés. Nous n'en sommes pas responsables.