Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

ADR-084 — Ratification air-url : couche 4 élargie (« frameworks développeur : UI + fondation ») + nom air-url

Statut : Accepté (2026-07-07, ratification BDFL). RFC de structure (ADR-015). Amende la macro-architecture (périmètre de la couche 4). Companion de la note api-reseau-strategie (qui posait la question) et de la spec air-url.

Catégorie : Architecture (placement de couche + nommage) / amendement macro-archi.

Note de procédure. La ratification suit l’hypothèse principale de la note (couche 4 élargie) ; le nom air-url est retenu (descriptif, vocabulaire Air, non copié d’Apple). Le BDFL peut réviser le nom (alternatives : air-web, air-fetch) sans rouvrir la décision de couche.

Contexte

La spec air-url (équivalent fonctionnel de URLSession : sessions, tâches data/download/upload/WebSocket, cache, cookies, auth, transferts en arrière-plan) a été rédigée en laissant deux points ouverts (note api-reseau-strategie) : la couche et le nom. air-url est une commodité applicative (URL-loading haut niveau bâti sur air-http), pas un mécanisme système ni un protocole filaire — exactement comme URLSession vit chez Apple dans Foundation, pas dans le socle réseau.

La couche 4 était jusqu’ici définie « UI seulement » (air-ui graphique / air-tui console). Placer air-url y élargit ce périmètre.

Décision

  1. Couche 4, périmètre élargi. La couche 4 passe de « frameworks UI » à « frameworks développeur : UI + fondation ». Elle héberge, à côté des frameworks d’interface (air-ui/air-tui), les commodités applicatives de fondation — dont air-url (URL-loading), sur le modèle de Foundation d’Apple (UIKit et Foundation coexistent au niveau « framework développeur »).
  2. Nom : air-url. Descriptif (chargement d’URL), vocabulaire Air, jamais « URLSession » (pas de copie d’API/nom Apple, décision de la note). Alternatives consignées : air-web, air-fetch (révisables par le BDFL sans rouvrir la couche).

Conséquences

  • Macro-architecture amendée : la section « Couche 4 » inclut désormais les frameworks de fondation (pas seulement UI). air-url y figure.
  • Précédent : les futures commodités applicatives (au-dessus des services système, destinées aux développeurs d’apps .airapp) se placent en couche 4 fondation (ex. formats, i18n applicative, etc., à instruire au cas par cas).
  • air-url : spec passée de « couche à confirmer » à couche 4 (fondation) ratifiée ; bâtie sur air-http (L2) + air-network (L2).
  • Non affecté : air-http/air-network/air-tls… restent en couche 2 (frameworks système / protocoles). L’élargissement ne concerne que la couche 4.

Alternatives rejetées

  • Haut de couche 2. Placerait un confort applicatif parmi les frameworks système / protocoles (transport, TLS, HTTP). Mélange les registres ; la couche 2 est « mécanisme système », air-url est « commodité développeur ». Rejeté au profit de la cohérence de registre (Foundation ≠ socle réseau).
  • Nouvelle couche dédiée (entre 2 et 4). Sur-ingénierie ; la couche 4 « frameworks développeur » couvre naturellement UI et fondation. Rejeté.
  • Nom URLSession/air-url-session. Copie de l’API/nom Apple, contraire à la note (« couverture fonctionnelle, pas copie d’API »). Rejeté.

Adoption

  • Amendement macro-architecture (section couche 4) appliqué. Spec air-url mise à jour (statut ratifié). Câblage registre/SUMMARY/INDEX. Le nom de crate air-url est retenu (révisable par le BDFL, sans impact sur la décision de couche).