Maintenant qu'on sait de quoi on parle, voyons à quoi ressemble le cœur du protocole.
À la base XMPP c'est 3 (anciennement 2)
RFCs: la 6120, la 6121, et la 6122 (il y en a d'autres, mais ces 3 là sont les principales). Elles expliquent tout le cœur comme l'envoi de messages, les informations de présence, les statuts, etc.
Sans trop entrer dans les détails qui vont concerner surtout les développeurs, on peut rapidement expliquer que XMPP se base sur 3 types d'éléments, ou « stanzas »:
- <presence/> pour indiquer principalement… notre information de présence (parfois on y accroche aussi d'autres choses comme des infos sur notre avatar ou nos capacités, mais ne nous égarons pas). La présence est relayée par votre serveur à toutes les personnes à qui vous avez donné l'accès (voir plus bas).
On peut associer un état et un message à notre présence. L'état peut être un des suivants (les noms peuvent changer selon votre client)
- disponible (par défaut): vous êtes en ligne normalement
- away (absent): vous êtes absent pour une courte période
- chat (discussion): vous avez particulièrement envie de parler
- dnd (do not disturb – ne pas déranger): vous êtes occupé (souvent appelé « busy » aussi dans les clients)
- xa (eXtended Away – durablement absent): vous êtes absent pour une longue période
Le message de statut permet spécifier en langage clair votre disponibilité (par exemple « je regarde un film, ne pas déranger »), même si en pratique c'est utilisé pour tout type de message (beaucoup de gens mettent une citation par exemple).
- <message/> un envoi de message de type j'envoie et j'oublie. Il existe 5 types de messages :
- chat (discussion): le plus connu, celui qui sert à la messagerie instantanée simple
- error (erreur): celui-là est normalement géré par les logiciels directement, il se traduit souvent par un fenêtre vous indiquant dans votre client que quelque chose s'est mal passé
- groupchat (discussion de groupe): comme « chat », mais pour les discussions à plusieurs. En pratique la différence ne concerne que les développeurs et cela devrait être transparent dans le client
- headline (manchette): un message important, une annonce. Normalement, ces messages ne sont pas gardés hors ligne, aussi si vous n'êtes pas connecté au moment du message, vous ne devriez pas l'avoir. Ces messages ne sont pas faits pour y répondre. Un exemple typique est une annonce de maintenance du serveur imminente
- normal : un type méconnu et pourtant intéressant. Il s'agit d'un message ayant généralement un sujet, et en dehors d'une conversation instantanée. Oui oui, exactement comme un courriel ! C'est plus ou moins son équivalent XMPP.
À cela s'ajoute la gestion des « thread » (fils de discussion), mais nous en parlerons une autre fois.
- <IQ/> (Info/Query – information/requête): utilisé pour tout ce qui est de type question/réponse (il est obligatoire de répondre à une requête <IQ/>, au pire par une erreur). Son utilisation concerne plutôt les développeurs, c'est la base de la plupart des fonctionnalités que vous utilisez : cet élément sert à dire « je veux connaître ou modifier telle information »
Je ne veux pas trop entrer dans les détails techniques, mais il me semble essentiel de connaître les différents types de messages et de présences pour bien comprendre son client.
À noter un point excellent avec XMPP, et largement sous exploité : XMPP sait nativement gérer les différentes langues, grâce à son héritage de XML (xml:lang). Autrement dit, vous pouvez spécifier un message normal ou de statut à la fois en français, en allemand et en slovaque. C'est un atout majeur que nous comptons bien exploiter dans Libervia.
Passons maintenant à une autre partie essentielle : la liste de contacts.
Dans le monde XMPP, on l'appelle « roster » (qui se traduit par « liste » ou « tableau de service »). À chaque contact que vous y ajoutez, vous pouvez associer 0, 1 ou plusieurs groupes (« famille », « amis », etc), un nom (donné par l'utilisateur et non le contact), ainsi qu'une information d'abonnement (« subscription »).
L'abonnement permet de savoir si vous avez autorisé votre contact à avoir votre information de présence, et si le contact vous a autorisé à voir la sienne. C'est pour cela que quand quelqu'un vous ajoute dans sa liste de contacts, votre client, par exemple Gajim, vous demande si vous l'autorisez à connaître votre information de présence. Il est tout à fait possible d'avoir autorisé un contact à vous voir sans qu'il ne vous autorise à le voir (et inversement évidemment), voir qu'aucun des deux ne soit autorisé à voir la présence de l'autre (mais je pense que la plupart des clients suppriment le contact du roster dans ce cas).
Les groupes sont associés aux contacts, et non l'inverse (ce n'est pas une liste liste de groupes qui contiennent des contacts), c'est la raison pour laquelle il est impossible d'avoir un groupe sans contact associé (c.-à-d. vide).Là encore les groupes sont à mon sens sous-exploités dans le monde XMPP, nous y reviendrons.
Voilà pour aujourd'hui. J'ai finalement préféré couper la partie extensions pour le prochain article, pour éviter de trop charger.