Maison : ça m'affiche sur une même page, les horaires des différentes lignes bus qui passent à côté de chez moi pour mener à la gare.
(
(
(pour lire les épisodes précédents, suivez l'étiquette correspondante)
Aujourd'hui nous allons expliquer dans les grandes lignes comment fonctionnent « PubSub » et « PEP », et voir à quoi cela peut servir. Cet article va reprendre en partie ce que j'ai dit à la conférence « PubSub, microblogage et XMPP » en juillet dernier aux RMLL.
PubSub signifie « Publish/Subscribe » (Publication/Abonnement), c'est un mécanisme qui permet à une ou plusieurs personnes de publier toutes sortes d'informations sur un endroit connu (qu'on appelle un nœud) et aux personnes qui le désirent de s'abonner, c'est à dire d'avoir accès au contenu et d'être averti des modifications, le tout avec un système d'accès simple. Il s'agit du patron de conception « observateur/observable » décentralisé et appliqué à XMPP.
Le fonctionnement est expliqué dans la XEP-0060, c'est une des XEPs les plus longues de XMPP mais le principe est relativement simple à comprendre. Sans reprendre le long glossaire du document, expliquons quelques termes :
- le service PubSub est l'entité qui gère le mécanisme de publication, d'autorisation, d'abonnement, de notification. C'est une entité XMPP et un jid y est donc associé, c'est à lui que vous faites toutes les requêtes pour un nœud donné.
- le nœud est un espace associé à une publication. On peut associer ça à l'adresse d'un flux Atom.
- un « item » (élément) est une publication dans un nœud. On peut associer ça à un article dans un flux Atom.
- cet « item » contient un « payload » (charge utile), c'est à dire un contenu significatif qui dépend de la fonctionnalité utilisée. En effet la XEP-0060 décrit un mécanisme générique et souple, qui est ensuite utilisé dans des cas pratiques par d'autres extensions.
Un service PubSub est généralement un composant de votre serveur, mais ça peut-être n'importe quelle entité : votre serveur lui-même (c'est le cas avec PEP que nous allons voir ci-dessous), ou un client voire votre client lui-même (mais c'est assez rare – je n'ai jamais vu de client le faire –, car en général on utilise le service de son serveur).
Le mécanisme général est très simple et centré sur les nœuds : chaque entité (associée à un jid) à un rôle lié à ce nœud selon qu'elle l'ait créé, qu'elle soit publieur, abonné, banni ou sans lien avec le nœud. À ces rôles sont donnés des autorisations : le droit d'écrire (avec le « publish model » ou modèle de publication) et le droit en lecture (avec l'« access model » ou modèle d'accès).
Reprenons de manière un peu plus formelle. Les rôles dont nous avons parlé sont appelés « affiliations », et on peut avoir les suivantes:
- owner (propriétaire): en général celui qui a créé le nœud
- publisher (publieur): celui ou ceux (il peut y en avoir plusieurs) qui ont accès en écriture
- publish-only (publication seulement): droit d'écriture mais pas de lecture, c'est un cas peu fréquent.
- member (membre): quelqu'un qui est abonné au nœud
- none (rien): l'entité n'a pas de lien avec le nœud
- outcast (banni): l'entité a été explicitement interdite d'accès au nœud
La section 4.1 de la XEP-0060 fourni un tableau qui montre les autorisations selon l'affiliation. Ainsi on voit que le propriétaire peut publier ou configurer un nœud.
Les modèles d'accès (pour la lecture) définis dans la XEP-0060 sont les suivants:
- open (ouvert, public): tout le monde peut lire le nœud
- presence (présence – oui je traduis même pour un seul accent –) : si une entité est autorisée à voir la présence du publieur, alors elle peut accéder au nœud
- roster (liste de contacts): si une entité est dans un groupe défini (dans la configuration du nœud) de la liste de contacts du service pubsub, elle a accès au nœud.
- whitelist (liste blanche): des entités sont explicitement autorisées dans la configuration du nœud
Et rapidement les modèles de publication:
- publishers (publieurs): quelqu'un qui a l'affiliation publieur peut écrire
- subscribers (abonnés): n'importe quel abonné peut écrire
- open (ouvert/libre): tout le monde peut écrire
Il faut bien noter une chose essentielle dans PubSub : quand la combinaison autorisation/abonnement/configuration le permet, on reçoit une notification immédiatement quand un élément est publié, modifié ou supprimé. Autrement dit on n'est plus du tout dans l'analogie avec un flux Atom – où on doit aller vérifier régulièrement qu'il n'y a rien de nouveau –, on est prévenu si nécessaire. Ceci est beaucoup plus efficace, rapide, et économe en ressources.
Voilà pour la base. La XEP défini d'autres choses qu'il n'est pas forcément pertinent d'expliquer ici, comme les métadonnées ou les inscriptions temporaires. On peut toutefois s'arrêter sur les collections, qui ne sont que mentionnées dans la XEP-0060 mais décrites en détails dans la XEP-0248. Elles permettent de faire des arbres de nœuds, et ainsi de représenter des données avec des relations entre elles. Des exemples valent parfois mieux qu'un long discours: les collections peuvent être utilisées pour représenter un système de fichiers sur un disque dur, ou un arbre généalogique.
Tout ceci est souple, générique, puissant, et relativement facile à utiliser par un client. Mais la XEP étant très longue, et l'implémentation de la partie service plus complexe, les implémentations ont mis du temps à arriver (et encore aujourd'hui elles sont très inégales). Comme PubSub peut être intéressant même sans tout le mécanisme, une version simplifiée est décrite dans la XEP-0163: « Personal Eventing Protocol » (Protocole d'évènements personels).
Cette dernière se base sur PubSub, mais définit les règles suivantes qui simplifient beaucoup :
1 compte (jid) = 1 service : probablement la règle la plus importante, elle évite d'avoir à chercher un service PubSub associé à un jid, puisque le service est l'adresse canonique (« bare jid ») de l'entité. Ainsi pour la microblogage (XEP-0277), il suffit de connaître le jid de la personne – le nœud étant défini dans la XEP – pour retrouver ses publications.
1 publieur par nœud : le propriétaire et le publieur sont le même, et il n'y a qu'un publieur par nœud. On se coupe ainsi de l'édition collaborative par souci de simplification, et il faudra utiliser PubSub pour ce genre d'applications.
accès par présence par défaut : sans rien toucher, il suffit d'avoir quelqu'un dans sa liste de contacts (et qui a accès à la présence) pour qu'il soit autorisé à voir nos publications
notifications filtrées sur l'intérêt exprimé : pour éviter d'être submergé de notifications, une entité/un client doit explicitement indiquer qu'il est intéressé par tel ou tel nœud
options par défaut au plus simple
PEP était utilisé au début pour des événements (sans grand intérêt à mon sens) comme l'humeur ou la musique en cours d'écoute, mais depuis son utilisation a évolué.
Voici, pour finir, quelques exemples d'utilisation de PubSub ou PEP:
- enregistrement de données publiques ou semi-publiques (XEP-0222), par exemple une clef publique de chiffrement
- enregistrement de données privées (XEP-0223), très utile pour n'importe quelle donnée de petite taille
- les marque-pages (XEP-0048) utilisés pour les salons de discussions utilisent PEP (la XEP-0048 a été modifiée après l'apparition de PEP pour s'y adapter)
- le microblogage bien entendu (XEP-0277), qui utilise PEP et utilise du Atom pour sa « charge utile » (« payload ») et un accès en général public. Les commentaires sont sur un nœud PubSub séparé, en général avec un modèle de publication par abonnement.
- la XEP-0214 utilise PubSub et les collections pour faire un dépôt de fichiers
- le futur protocole de discussions de groupe « MUC 2 » devrait se baser sur PubSub
PubSub pourrait aussi être utilisé pour placer des points sur une carte, faire un wiki, organiser des événements, ou encore gérer et surveiller une batterie de serveurs qui nous préviendraient en cas de problème.
Je reviendrai sûrement plus tard sur tout ça pour expliquer le microblogage ou d'autres extensions.
La prochaine fois, je pense vous parler de Jingle (mais pas de la partie vidéo-conférence). J'espère qu'à ce stade vous commencez à comprendre que XMPP n'est pas une technologie, mais un ensemble de technologies coordonnées et qui se réutilisent les unes les autres quand nécessaire.
J'ai un peu réduit le rythme des articles ces derniers temps car je travaille sur mon projet, et qu'une partie a été traduite en anglais avec l'aide de pas mal de monde (merci encore !), tout cela prend du temps.
Si vous venez à la fête de l'huma ce week-end, vous pourrez me trouver au village du libre, où Parinux me prête gentiment un bout de stand (merci aussi !). Je n'y serai pas en permanence, car je compte aussi profiter un peu de la fête :)
