## Construire des téléphones avant de comprendre le réseau
Au départ, je voulais surtout fabriquer des téléphones dans Minecraft.
Pas une simulation affichée sur un écran externe. De vrais objets du jeu, avec leur propre interface, capables de contacter un serveur, d’accéder à des comptes et de fonctionner avec des bornes ATM.
CC:Tweaked fournit le terrain. Le mod ajoute des ordinateurs programmables en Lua, et ses modems savent transmettre des messages entre plusieurs machines. (github.com)
Sur le papier, le réseau était donc déjà là.
En pratique, j’avais seulement un moyen de déplacer des données.
Le modem ne savait pas ce qu’était un téléphone, une installation ou une demande de compte. Il pouvait transporter une table Lua, mais pas lui donner un sens. Cette partie-là restait entièrement à construire.
## Le transport ne suffit pas
Dans PIL OS, les machines communiquent avec rednet, la couche réseau fournie par CC:Tweaked au-dessus des modems. Elle permet notamment d’envoyer un message à un ordinateur précis, de recevoir une réponse et d’utiliser un nom de protocole pour filtrer les échanges. (tweaked.cc)
Mais appeler ce protocole cobblenet ne définit toujours aucune règle.
Il faut encore décider de la forme des messages. Par exemple, l’installation du téléphone envoie une table de ce type au serveur :
{
action = "install",
pkg = "pocketos"
}Ce petit objet contient déjà une langue.
action indique ce que la machine demande. install fait partie du vocabulaire accepté. pkg complète la demande. pocketos désigne la ressource attendue.
Une autre machine peut envoyer une table Lua parfaitement valide, avec les mêmes clés mais une action inconnue. Le transport aura réussi. Le message aura traversé Minecraft. Pourtant, la communication aura échoué.
C’est là que j’ai arrêté de confondre réseau et protocole.
Le réseau répond à la question « comment faire passer cette table d’une machine à une autre ? ». Le protocole répond à des questions moins visibles :
- quelles actions existent ;
- quels champs sont obligatoires ;
- quelle réponse correspond à quelle demande ;
- combien de temps un client attend ;
- comment il reconnaît un échec.
## Des règles de jeu écrites dans des tables Lua
Minecraft rend cette distinction très concrète parce que chaque ordinateur est aussi un bloc posé dans le monde.
Je peux voir le serveur. Je peux tenir le téléphone. Je peux installer une borne. Pourtant, aucune de ces machines ne se comprend naturellement. Elles ne partagent que les règles que j’ai écrites.
C’est assez proche d’un jeu : les objets n’ont un comportement cohérent que parce qu’un ensemble de règles leur donne un sens commun.
Dans PIL OS, une demande d’installation attend une réponse pendant un temps limité. Le client vérifie ensuite que la réponse contient bien data.files avant d’écrire les fichiers et de redémarrer. Pour la borne ATM et la console d’administration, le principe reste le même, même si les paquets demandés changent.
Je n’avais pas de framework pour masquer cette mécanique. Pas de route HTTP, pas de contrôleur généré, pas de client typé. Seulement des tables Lua envoyées par modem et du code qui devait décider quoi en faire.
Cette contrainte m’a obligé à regarder une API pour ce qu’elle est vraiment : un vocabulaire partagé, accompagné de règles d’interprétation.
## Ce que je veux rendre explicite
Aujourd’hui, ce vocabulaire existe surtout dans le code qui produit et traite les messages. Il fonctionne, mais il faut parcourir les branches du serveur et les appels des clients pour reconstruire le contrat complet.
C’est le prochain point que je veux rendre plus net dans PIL OS : regrouper les actions et la forme de leurs réponses au même endroit, sans transformer le projet en usine à abstractions.
Le modem continuera seulement à transporter des tables. Mais au moins, la langue parlée par mes téléphones ne sera plus cachée entre deux if.