Кратко

  • В RFC 5267 обновляемый контекст состоит из начального результата и позиционных операций ADDTO/REMOVEFROM, которые относятся к тегу исходной команды и применяются строго в порядке получения.
  • Стандарт прямо исключает механизм snapshot. Сервер может отказать через NOUPDATE, а CANCELUPDATE, снятие выбора ящика или необъяснимый разрыв транспорта прекращают непрерывность.

Движение интерфейса подтверждает реакцию, но не полноту

Новое письмо появляется без перезагрузки. После изменения флага другая строка исчезает. Счётчик следует за ними. Такой экран легко назвать текущим состоянием, хотя каждый видимый жест доказывает лишь доставку отдельного изменения, а не сохранность всей истории.

RFC 5267 позволяет запросить UPDATE в SEARCH, UID SEARCH, SORT или UID SORT. Сначала сервер возвращает базовый результат, затем может присылать незапрошенные ESEARCH с ADDTO и REMOVEFROM. Коррелятор содержит тег исходного поиска. Значит, изменение относится к конкретному вопросу, режиму идентификаторов и порядку, а не является универсальным событием почтового ящика.

CONTEXT — только подсказка о вероятном повторном использовании критериев. Сервер вправе построить кэш или индекс либо проигнорировать подсказку; внешнее поведение от этого зависеть не должно. Именно поэтому RFC говорит, что snapshot facility отсутствует. Клиент располагает не сохранённой фотографией, а исходной точкой и последовательностью, непрерывность которой обязан доказать.

ADDTO и REMOVEFROM — позиционная программа изменений

ADDTO задаёт позицию и результаты для вставки, REMOVEFROM — позицию и результаты для удаления. SEARCH и SORT используют номера последовательности сообщений, UID-варианты — UID. Позиции делают порядок операций частью смысла: перестановка двух шагов способна дать другой список.

Клиент обязан обрабатывать элементы в порядке появления, в том числе несколько элементов в одном ESEARCH. Сервер обязан формировать их так, чтобы последовательное применение сохраняло запрошенный порядок. Параллельные потребители с последующей сортировкой по локальным меткам времени могут создать состояние, которого протокол не задавал.

Минимальная доказательная запись включает поисковую программу, режим идентификаторов, сортировку, тег, начальный упорядоченный результат и монотонную последовательность приёма. Тег активного контекста нельзя использовать для нового: сервер должен ответить BAD. Этот тег связывает незапрошенное изменение с вопросом, придавшим ему смысл.

EXISTS и EXPUNGE задают срок действия номера

После expunge номера последовательности смещаются. Поэтому ADDTO с такими номерами, вызванный доставкой или append, должен идти после EXISTS: только тогда новые номера действительны. REMOVEFROM, вызванный expunge, должен идти до EXPUNGE, пока старая нумерация ещё позволяет понять удаление.

EXISTS, FETCH, ESEARCH и EXPUNGE образуют единый причинный журнал. Разнести их по независимым очередям и затем склеить по часам разных сервисов — значит потерять нормативный порядок. ESEARCH может прийти без выполняемой команды, во время другой команды или при IDLE. Наблюдение только за парами запрос–завершение не сохраняет сам поток обновлений.

Номера внутри поискового критерия имеют отдельную границу: они вычисляются при получении команды. Позднейшая перенумерация сама по себе не вызывает уведомления. Истолковать то же числовое выражение в новом состоянии — выполнить другой поиск.

NOUPDATE оставляет ответ, но отнимает обещание продолжения

Сервер может отказаться поддерживать обновления, например из-за внутреннего предела контекстов. Он посылает незатегированное NO с кодом NOUPDATE и тегом затронутой команды. Остальные return options всё равно должны выполняться.

Поэтому клиент способен получить полезные строки и успешное завершение, не получив запрошенного сопровождения. Если сохранить строки, но выбросить NOUPDATE, статический ответ будет выглядеть живым. Состояния должны различать запрос, принятие, отказ, активность, отмену, завершение после снятия выбора и неизвестную непрерывность.

Стандарт требует хотя бы один обновляемый контекст на клиента и рекомендует больше, но учитывает более высокую стоимость сортированного контекста. Отказ для SORT не доказывает отказ для простого SEARCH. Допустимы повторная попытка и явный статический режим; недопустимо скрыть отказ.

PARTIAL ограничивает окно, а не поток

PARTIAL возвращает позиционный фрагмент результата и удобен для виртуальных списков. Но UPDATE не сужается другими return options. Вместе с PARTIAL он может сообщать об изменениях за пределами видимого окна. COUNT, MIN и MAX также не ограничивают обновления своим агрегатом.

Если интерфейс отбрасывает невидимые дельты, будущие позиции теряют основание. Продукт может не поддерживать весь контекст, но тогда обязан объявить его недействительным и получить новую базу. Видимая область — проекция, не граница полномочий.

Поток после разрыва не восстанавливает пропущенный шаг

Обновления прекращаются, когда ящик перестаёт быть выбранным или CANCELUPDATE называет исходные теги. Повторное подключение, выбор или запрос с теми же критериями создают новое наблюдение, а не продолжают старое.

Кроме явного обрыва, возможны частичная ошибка parser, потеря при backpressure или автоматическое соединение с сохранением старого UI. Если могла исчезнуть одна позиционная операция, последующие не доказывают полноту. CONDSTORE и QRESYNC предлагают отдельный путь синхронизации со своими условиями. IDLE помогает принимать незапрошенные ответы, NOTIFY задаёт интерес к событиям. Само наличие этих возможностей не чинит неполный журнал RFC 5267.

Принцип приоритета работающего кода требует управлять не названием функции «живой поиск», а фактической командой, поколением возможностей, выбранным ящиком, базой, упорядоченными патчами и границей завершения. Начальное наблюдение, принятие UPDATE, реконструированный список, показанная страница и действие пользователя принадлежат разным слоям реальности. Если строку нельзя вернуть к тегу и причинному порядку, организация имеет убедительное представление, но не доказательство настоящего.

Источники