1.3 KiB
1.3 KiB
issueRef, version, updatedBy, updatedAt
| issueRef | version | updatedBy | updatedAt | ||||
|---|---|---|---|---|---|---|---|
| #127 | 4 |
|
1785669121141 |
Problème
Sans bus d’événements ou API de watch publique, un plugin doit poller l’état du host ou du workspace pour se tenir à jour. C’est coûteux, fragile et peu réactif.
Pourquoi c’est global
Tout plugin de dev outillé peut avoir besoin de réagir à :
- changement de fichier
- fin/échec d’une tâche
- changement de projet courant
- autres événements système ou host pertinents
Ce que ce ticket doit produire
Une API publique d’abonnement permettant au minimum :
- souscription/désinscription propre
- typage minimal des événements publics
- événements documentés et versionnables
- stratégie claire sur rétention/perte d’événements
Contraintes d’architecture
- Exposer uniquement des événements publics stables.
- Ne pas refléter brut de décoffrage les événements internes du host.
- Bien définir les garanties: best effort vs livraison fiable.
Non-objectifs
- Pas de protocole temps réel cross-process complexe si non nécessaire.
- Pas d’événements spécifiques Android.
Critères d’acceptation
- Un plugin peut se mettre à jour sur changements du workspace/host sans polling permanent.
- L’API de subscription est proprement disposable et documentée.