Note de cadrage — stratégie d’API réseau Air (air-network + équivalent URLSession)

Statut : décisions de périmètre validées par le BDFL (2026-06-13), implémentation non engagée. Forward-looking : grave les cibles de couverture et le placement pour quand on spécifiera les couches 2/4. Toute mise en œuvre passera par des specs

• ADR le moment venu.

Décision (a) — couverture fonctionnelle d’Apple, pas copie d’API

Air vise, pour les développeurs, la même couverture fonctionnelle que les API réseau d’Apple — mais en aucun cas on ne copie leur API. Surface en vocabulaire Air idiomatique (Rust), pas de compat API/ABI Swift/Obj-C. Leur documentation sert de checklist de couverture et de nord de conception, rien de plus.

air-network (couche 2) — équivalent de Network.framework

• Renommage acté : air-network → air-network (sweep grep sur tout docs/, aucune référence cassée ; air-socket.md + macro-architecture-fr.md).
• C’est le framework de connexion sémantique de couche 2 qu’air-socket (L1) réserve déjà explicitement. Bâti sur air-socket (sockets bas niveau + résolveur enfichable) + le runtime async io_uring (ADR-023) + air-tls (à spécifier).
• Référence de couverture : https://developer.apple.com/documentation/network.
• Concepts à couvrir (exprimés en vocabulaire Air, pas en noms Apple) : connexion (≈ NWConnection), listener (≈ NWListener), découverte de service (≈ NWBrowser/ Bonjour), conscience du chemin réseau (≈ NWPath/NWPathMonitor : wifi/ cellulaire, lien expensive/constrained, better path), paramètres + pile de protocoles déclaratifs (≈ NWParameters/NWProtocolStack : TCP/UDP/QUIC/TLS), TLS intégré par défaut. Bon fit Air : sécurité-d’abord + conscient du matériel/ réseau variés.

Équivalent URLSession — client HTTP/URL-loading haut niveau

• Apple construit URLSession au-dessus de Network.framework (cf. leur doc) ; Air fait pareil : un client haut niveau bâti sur air-network.
• À noter et implémenter (Thierry). Couverture à viser (vocabulaire Air) : sessions + tasks (data/download/upload), cache, cookies, défis d’authentification, transferts en arrière-plan, WebSocket (≈ URLSessionWebSocketTask). Référence : https://developer.apple.com/documentation/foundation/urlsession.
• Couche d’intégration — hypothèse principale : couche 4 (« frameworks applicatifs »), à condition d’élargir la couche 4 de « UI seulement » (air-ui/air-tui) à « frameworks développeur (UI + fondation) » — URLSession est chez Apple dans Foundation, une commodité applicative, pas un mécanisme système. Alternative : haut de couche 2 (service fondamental). À trancher quand on spécifiera (probable clarification macro-archi / ADR). Nom Air à définir (ex. air-http / air-url-session).

À faire (le moment venu, pas maintenant)

1. Spec air-network (couche 2) avec la doc Network.framework comme checklist.
2. Spec air-tls (déjà notée comme différée dans air-crypto).
3. Spec de l’équivalent URLSession (couche à confirmer — couche 4 élargie), bâti sur air-network.
4. Renommage air-network → air-network (sweep) à intégrer au prochain landing doc.

Liens

air-socket (L1, réserve air-network couche 2) · air-crypto / air-tls différé · ADR-023 (runtime async io_uring) · ADR-016/ADR-024 (dépendances) · macro-architecture (couches 2 et 4).

Licence du document : MPL 2.0 Statut : note de cadrage, implémentation non engagée. Specs + ADR à produire.