Skip to main content
Chaque choix structurant d’OxiMail est consigné dans un Architecture Decision Record avant d’être implémenté : le contexte, la décision, les alternatives écartées et les conséquences. Les ADR sont des documents d’ingénierie de travail dans le dépôt du serveur ; quand le dépôt AGPL s’ouvrira publiquement, les textes complets viendront avec. D’ici là, cet index liste ce qui existe (numéro, statut, titre) pour rendre visibles la profondeur et la direction de l’architecture. Les statuts : Accepted (en vigueur, implémenté sauf mention), Design (décision gravée, implémentation suivie), Superseded (remplacé par un ADR ultérieur ; les parties conservées sont notées dans le titre), Proposed/Reserved (pas encore ratifié). Les titres sont laissés en anglais, la langue de rédaction des ADR. La numérotation a des trous : l’espace de numéros est partagé avec des dépôts compagnons, certains numéros vivent donc hors du dépôt AGPL du serveur et ne sont pas listés ici.
Design n’est pas synonyme de livré, et Accepted ne l’est pas davantage. Plusieurs enregistrements de fédération ci-dessus (124, 126, 127) sont ratifiés comme architecture de référence avec un mécanisme partiellement construit : la cérémonie d’appairage, le modèle de grant et les premières lectures fédérées (le temps occupé, les partages du Drive en lecture seule) sont déployés, tandis que certaines clauses nommées à l’intérieur, à commencer par le dépôt de courrier, restent ouvertes (fédération). L’ADR-149 est en Design avec quatre de ses lots en production ; les ADR-135 et 136 occupent l’autre extrémité de la même échelle : la décision est gravée et rien n’en est servi, ni la dimension category ni le type malware n’existent sur le fil, et l’ADR-136 a été dépassée avant sa première marche. Là où cette documentation décrit un comportement, elle décrit ce qui est servi ; la colonne de statut des ADR décrit, elle, l’état de la décision.