Mon blog

Voici un des RFC du projet TAPS, qui vise à proposer une vision cohérente des protocoles de transport aux applications. Ce RFC décrit (mais de manière assez abstraite) l'API de TAPS.

Avant de le lire, il est très fortement recommandé de réviser le RFC 9621, qui décrit les buts du projet TAPS, et les principes de l'API Transport Services (autrefois surnommée « post-sockets »). Mais le RFC 9621 restait assez abstrait, et notre RFC 9622 se fait un peu plus concret (sans aller jusqu'à une vraie API puisqu'il reste partiellement indépendant du langage de programmation utilisé).

Rappelons quelques principes de TSAPI (Transport Services API, l'API qui est le but final du projet TAPS). D'abord, l'API est asynchrone (ce qui n'est pas idéal pour les langages avec parallélisme comme Go ou Elixir). On crée des Connexions (la majuscule au début est là pour se distinguer du concept flou de connexion, et pour désigner un type d'objets particulier), voire des Préconnexions si on veut les configurer avant, on leur définit des propriétés (en indiquant si elles sont impératives ou facultatives), on peut ensuite activer les Connexions (ou écouter passivement que l'autre machine les active), puis on envoie et on reçoit des Messages. La section 3 du RFC résume l'API, et, si vous êtes pressé·e, vous pouvez vous contenter de cette section. Elle contient quelques exemples pratiques, en pseudo-code.

À propos de pseudo-code, le RFC note que les conventions de nommage de l'API ne pourront pas forcément être suivies religieusement par toutes les mises en œuvre puisque certains langages de programmation ont des règles différentes. Mais c'est un détail.

Parmi les points dignes d'intérêt dans le RFC, on note que les applications peuvent indiquer le domaine d'avitaillement (PvD, ProVisioning Domain, défini dans le RFC 7556) qu'elles veulent utiliser. Elles peuvent par exemple l'identifier par son nom de domaine (RFC 8801).

Autre point intéressant, les cadreurs (framers). Décrits dans la section 9.1.2, ce sont des couches logicielles qui vont mettre en œuvre les exigences du protocole sous-jacent. Lors d'une opération d'envoi ou de réception d'un Message, les cadreurs vont tenir compte du protocole pour transformer un Message en flux d'octets et réciproquement. (Le RFC suggère de regarder le RFC 9329, pour un exemple.)

Pour mettre en œuvre cette API assez abstraite dans un langage de programmation spécifique, l'annexe A du RFC donne quelques conseils. Il y a des mises en œuvre de TAPS (plusieurs sont listées dans le RFC 9623, annexe C). On peut citer :

• En Python, PyTaps, mais qui n'est plus maintenu depuis longtemps (le projet TAPS existe depuis des années et ne semble pas susciter d'enthousiasme délirant),
• En C, NEAT, qui semble également abandonné.

Notez un point positif dans le RFC : l'annexe C du RFC 9623, qui décrit les mises en œuvre existantes donne non seulement les URL « normaux » du projet, et ceux sur GitHub mais aussi un lien Software Heritage, pour la pérennité. C'est une très bonne chose, car certains RFC ont une longue durée de vie). Par exemple, NEAT est https://github.com/NEAT-project/neat mais aussi https://archive.softwareheritage.org/swh:1:dir:737820840f83c4ec9493a8c0cc89b3159e2e1a57;origin=https://github.com/NEAT-project/neat;visit=swh:1:snp:bbb611b04e355439d47e426e8ad5d07cdbf647e0;anchor=swh:1:rev:652ee991043ce3560a6e5715fa2a5c211139d15c.