Résumé

  • Avec RFC 5267, le résultat courant est le résultat initial auquel le client applique, dans l’ordre, les opérations positionnelles ADDTO et REMOVEFROM rattachées au tag de la commande d’origine.
  • Le texte exclut expressément toute fonction d’instantané. NOUPDATE peut laisser parvenir un résultat initial sans promesse de suivi, et la continuité cesse avec CANCELUPDATE, la désélection de la boîte ou toute perte inexpliquée du flux.

La fluidité de l’écran ne prouve rien sur le passé

Dans une interface de messagerie, la fraîcheur se donne en spectacle. Un message arrive et s’insère. Un changement de drapeau fait disparaître une ligne. Le compteur suit. Cette chorégraphie encourage une conclusion abusive : si la liste réagit, elle doit être complète.

RFC 5267 ne promet pas « la liste courante » comme objet autonome. Une commande SEARCH, UID SEARCH, SORT ou UID SORT demande UPDATE. Le serveur livre une base, puis peut émettre des réponses ESEARCH non sollicitées contenant ADDTO ou REMOVEFROM. Le corrélateur renvoie au tag de la commande qui a créé le contexte. C’est cette chaîne qui porte l’autorité, pas le dernier dessin affiché.

La norme dit même qu’il n’existe pas de mécanisme d’instantané. CONTEXT est un indice : le serveur peut s’en servir pour maintenir un cache ou un index, mais il peut aussi l’ignorer. Son choix interne ne doit pas modifier le comportement visible. Le client ne peut donc pas prétendre qu’un état gelé l’attend côté serveur. Il peut seulement démontrer qu’il possède un point de départ et tous les changements qui l’ont suivi.

ADDTO et REMOVEFROM forment un langage de modification

Ces deux éléments ne sont pas de simples événements métier. ADDTO indique une position et les résultats à insérer dans l’ordre demandé. REMOVEFROM indique une position et les résultats à retirer à partir de celle-ci. SEARCH et SORT travaillent en numéros de séquence ; UID SEARCH et UID SORT en UID.

Le client doit appliquer les éléments dans l’ordre où ils apparaissent, y compris lorsqu’une seule réponse ESEARCH en contient plusieurs. Le serveur doit les produire de façon à maintenir l’ordre demandé. Inverser deux opérations positionnelles peut produire une autre liste. Un bus d’événements qui parallélise les traitements, puis trie les écritures selon une horloge locale, peut donc fabriquer un état que le protocole n’a jamais autorisé.

La trace minimale comprend le programme de recherche, le mode d’identifiant, l’ordre demandé, le tag, la liste initiale et un numéro de réception monotone pour chaque modification. Le tag ne peut d’ailleurs pas être réutilisé pour un autre contexte encore actif : le serveur doit rejeter la collision par BAD. Il ne s’agit pas d’une convention cosmétique, mais de la clé qui rattache une mise à jour non sollicitée à la bonne question.

Les numéros de séquence imposent une causalité au fil

Un numéro de séquence change de sens lorsque des messages sont expulsés. RFC 5267 encadre donc l’ordre autour des événements de boîte. Si une livraison ou un ajout provoque un ADDTO en numéros de séquence, ADDTO doit venir après EXISTS, moment où ces numéros deviennent valides. Si une expulsion provoque REMOVEFROM, celui-ci doit venir avant EXPUNGE, tant que l’ancien numérotage existe encore.

Il faut conserver un seul transcript causal pour EXISTS, FETCH, ESEARCH et EXPUNGE. Les répartir dans des files indépendantes puis tenter de les recoller par date locale détruit la règle normative. De plus, ESEARCH peut arriver sans commande en cours, pendant une autre commande ou sous IDLE. Une instrumentation limitée aux couples requête-réponse manque alors le cœur même du contexte vivant.

Les numéros présents dans le programme de recherche ont une autre limite : ils sont évalués à la réception de la commande. Une renumérotation ultérieure ne produit pas de notification simplement parce que ces opérandes désignent désormais autre chose. Réinterpréter plus tard la même expression numérique reviendrait à poser une nouvelle question.

Un résultat réussi peut cacher un refus de suivi

Le serveur peut refuser de fournir des mises à jour, notamment lorsqu’il atteint une limite interne. Il envoie alors un NO non sollicité, assorti du code NOUPDATE et du tag concerné. Les autres options de retour doivent néanmoins être honorées.

Le scénario est subtil : des lignes utiles arrivent, la commande se termine avec succès, mais le service de mise à jour demandé n’existe pas. Si le client conserve les lignes et jette l’avertissement, une vue statique peut porter les habits d’une vue vivante. La norme impose au moins un contexte actualisé par client et recommande davantage ; elle admet aussi qu’un tri coûte plus cher qu’une recherche non triée. Un repli est possible, jamais une falsification silencieuse du statut.

Le modèle d’exploitation doit donc distinguer demandé, accepté, refusé, actif, annulé, terminé par désélection et continuité inconnue. Le simple état « chargé » ne suffit pas.

La fenêtre visible n’est pas la surface d’autorité

PARTIAL renvoie une tranche positionnelle d’un résultat ordonné. C’est idéal pour une liste virtuelle qui ne charge que l’écran courant. Pourtant UPDATE n’interagit pas avec les autres options de retour. Associé à PARTIAL, il peut signaler des changements concernant des messages situés hors de la tranche affichée. MIN, MAX et COUNT ne réduisent pas davantage le périmètre du flux.

Une architecture qui ne conserve que le viewport perd alors les opérations nécessaires à la signification des positions futures. Elle peut choisir de ne pas maintenir le contexte complet, mais elle doit dans ce cas l’invalider et repartir d’une nouvelle base. Elle ne peut pas conserver d’anciennes positions après avoir jeté des changements « hors écran ».

Toute rupture transforme le direct en conjecture

Les mises à jour cessent lorsque la boîte n’est plus sélectionnée ou lorsqu’un CANCELUPDATE nomme le tag du contexte. Le serveur peut ensuite libérer ses ressources. Une reconnexion, une nouvelle sélection ou la répétition du même critère crée une autre observation ; elle ne ressuscite pas la précédente.

Une perte de transport, une erreur d’analyse ou un débordement de file a le même effet probatoire. Dès qu’une opération peut manquer, les suivantes ne réparent pas la liste. D’autres mécanismes peuvent aider à resynchroniser : RFC 7162 définit CONDSTORE et QRESYNC avec leurs propres conditions. Mais leur présence ne constitue pas une réparation automatique. IDLE permet de recevoir des réponses non sollicitées, NOTIFY exprime des intérêts d’événements ; aucun ne transforme un transcript troué en instantané.

La discipline issue de la primauté du code en fonctionnement est simple. La réalité n’est pas l’étiquette produit « recherche en direct », mais la commande exacte, sa base, chaque patch reçu et la frontière qui a mis fin à la continuité. Le résultat initial, l’acceptation d’UPDATE, l’état reconstruit, la page visible et l’action de l’utilisateur appartiennent à des couches différentes. Tant que le système ne peut pas remonter d’une ligne affichée jusqu’au tag et à l’ordre causal qui l’autorisent, il possède une présentation, pas une preuve.

Sources