Resumo

  • Na RFC 5267, um contexto atualizável é o resultado inicial somado a operações ADDTO e REMOVEFROM sensíveis à posição, aplicadas na ordem recebida e vinculadas à tag do comando original.
  • A norma declara que não existe mecanismo de snapshot. NOUPDATE pode preservar a resposta inicial sem aceitar o acompanhamento, enquanto CANCELUPDATE, deseleção ou qualquer falha não explicada encerram a continuidade.

O presente da interface depende de todo o passado do fluxo

Quando uma mensagem aparece sozinha em uma busca, o produto demonstra velocidade. Quando outra deixa de satisfazer o filtro e some, demonstra reação. Nenhum desses movimentos demonstra que o cliente recebeu tudo o que ocorreu entre a resposta inicial e a tela atual.

A RFC 5267 permite solicitar UPDATE em SEARCH, UID SEARCH, SORT ou UID SORT. O servidor entrega o ponto de partida e depois pode emitir ESEARCH não solicitado com ADDTO e REMOVEFROM. A correlação inclui a tag da busca de origem. Cada mudança pertence àquela pergunta, àquele modo de identificador e àquela ordenação; não é um evento genérico que possa ser aplicado a qualquer lista parecida.

CONTEXT apenas sinaliza que os critérios talvez sejam usados de novo. O servidor pode manter cache ou índice, ou ignorar a dica, sem alterar o comportamento observável. A própria RFC afirma que não há snapshot facility. A prova disponível ao cliente não é uma fotografia guardada no servidor, mas a posse verificável da base e de todos os deltas posteriores.

Posição transforma notificações em instruções

ADDTO informa onde inserir resultados na ordem pedida. REMOVEFROM informa de onde retirar resultados. SEARCH e SORT usam números de sequência; as variantes UID usam UIDs. Como as operações contêm posição, a ordem de aplicação muda o estado final.

O cliente deve processar os itens na ordem em que aparecem, inclusive quando uma única resposta ESEARCH traz vários deles. O servidor deve gerá-los de modo que esse processamento preserve a ordem solicitada. Paralelizar consumidores e depois ordenar pelo horário local pode produzir uma lista que nunca existiu no protocolo.

O registro auditável precisa conter consulta, modo de identificação, ordenação, tag, resultado inicial e sequência monotônica de recepção. Uma tag de contexto ativo não pode ser reutilizada para criar outro contexto; o servidor deve responder BAD. Ela é a chave causal que impede uma atualização espontânea de ser atribuída à busca errada.

Um número vale somente no momento correto do fio

Números de sequência mudam depois de expunge. Por isso, um ADDTO com números gerado por entrega ou append deve vir depois de EXISTS, quando os novos números já são válidos. Um REMOVEFROM provocado por expunge deve vir antes de EXPUNGE, enquanto a numeração antiga ainda tem sentido.

EXISTS, FETCH, ESEARCH e EXPUNGE formam um só transcript. Separá-los em filas e tentar remontá-los pelo relógio de serviços distintos elimina a ordem normativa. ESEARCH pode chegar sem comando em andamento, no meio de outro comando ou durante IDLE. Observabilidade restrita a pares de requisição e resposta deixa as atualizações fora do arquivo.

Há ainda a semântica do critério: números de sequência presentes na expressão de busca são avaliados quando o comando chega. Uma renumeração posterior não gera aviso só porque o mesmo número passou a apontar para outra mensagem. Reavaliar a expressão antiga no novo estado seria executar outra consulta.

NOUPDATE produz um resultado sem promessa de futuro

O servidor pode recusar novos contextos, por exemplo ao atingir um limite interno. Ele envia NO não etiquetado com o código NOUPDATE e a tag afetada. As demais opções de retorno continuam obrigatórias.

Assim, a aplicação pode receber linhas corretas e uma conclusão bem-sucedida, mas não o serviço contínuo pedido. Se guardar as linhas e ignorar NOUPDATE, um resultado estático ganha aparência de live. O estado operacional deve distinguir solicitado, aceito, recusado, ativo, cancelado, encerrado por deseleção e continuidade desconhecida.

A norma garante pelo menos um contexto atualizável por cliente e recomenda mais, mas reconhece que contexto ordenado pode custar mais. Uma recusa de SORT não implica recusa de SEARCH. O cliente pode tentar uma forma mais barata ou assumir explicitamente um resultado estático; não pode esconder a recusa.

PARTIAL recorta a exibição, não o dever de manter o contexto

PARTIAL entrega uma janela posicional e combina bem com rolagem virtual. Porém UPDATE não é limitado por outras opções. Junto com PARTIAL, ele pode relatar mudanças fora da janela visível. COUNT, MIN e MAX também não estreitam a atualização ao valor resumido.

Descartar deltas fora da tela quebra as posições das janelas futuras. Se o produto não pretende manter o conjunto completo, deve invalidar o contexto e obter outra base. A área visível é uma projeção, não a fronteira da autoridade.

Depois da lacuna, continuar recebendo não repara

As atualizações terminam quando a caixa deixa de estar selecionada ou quando CANCELUPDATE aponta para as tags originais. Reconectar, selecionar novamente ou repetir a mesma consulta cria outra observação. O contexto anterior não retorna.

Uma queda de conexão é evidente; uma perda no parser, descarte por backpressure ou reconexão automática que preserva o componente antigo pode ser silenciosa. Se um delta posicional talvez tenha faltado, os próximos não comprovam o estado. CONDSTORE e QRESYNC podem oferecer uma rota de ressincronização com requisitos próprios. IDLE ajuda a receber respostas espontâneas e NOTIFY declara interesse em eventos. Nenhum deles conserta automaticamente um histórico RFC 5267 incompleto.

Sob a primazia do código em execução, o objeto governável é o comando real, as capacidades, a seleção de caixa, a base, a sequência de patches e sua fronteira. Resultado inicial, aceitação de UPDATE, estado reconstruído, página exibida e ação humana são camadas diferentes da realidade. Sem caminho reversível de cada linha até tag e ordem causal, existe uma apresentação atualizada, não uma prova do presente.

Fontes