Кратко

  • Overview заменил множество запросов отдельных заголовков компактными строками с фиксированным началом и объявленным порядком дополнительных полей.
  • LIST OVERVIEW.FMT мог включить поле лишь тогда, когда база для каждой подходящей статьи зафиксировала его содержимое либо его отсутствие.
  • При смене схемы удаляемое поле следовало сначала убрать из объявления, а новое — не показывать до перестройки базы или естественного ухода старых записей.

Пустота зависит от обещания

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

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

RFC 3977 определил согласованность поля как запись либо его содержимого, либо факта отсутствия у всех применимых статей. База, которая сохранила значение лишь для части материалов и пропустила другие, где оно было, считается несогласованной. Такое поле нельзя обещать через LIST OVERVIEW.FMT.

До сводки заголовки получали по одному

В исходном RFC 977 команда HEAD возвращала заголовки выбранной статьи. Клиент указывал Message-ID или локальный номер. Ответ был подробным, однако для построения списка тем большой группы приходилось повторять операцию снова и снова.

RFC 2980 описал расширение XOVER. На диапазон номеров сервер отвечал одной компактной строкой для каждой сохранившейся статьи: номер, Subject, From, Date, Message-ID, References, число байтов и строк, затем возможные дополнительные поля. Пустое значение обозначалось соседними табуляторами.

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

Неподвижное начало и открыто описанный хвост

RFC 3977 стандартизировал команду OVER. Первые восемь позиций закреплены: номер статьи или ноль, Subject, From, Date, Message-ID, References, :bytes и :lines. Внутренние пустые поля сохраняют место; пустой конец строки можно не передавать.

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

Команда LIST OVERVIEW.FMT возвращала описания в том же порядке, в каком OVER выдавал поля. После обязательной части могли идти расширения; суффикс :full сообщал, что в значении сохраняется имя заголовка. Так расширяемость оставалась явной, а не зависела от догадки клиента.

Это описание не было вечной декларацией. RFC допускает изменение формата даже в пределах сеанса. Поэтому сохранённая вчера схема — лишь историческое наблюдение, а не право толковать сегодняшний ответ.

Новая колонка сначала оставалась невидимой

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

Порядок перехода в RFC 3977 сохраняет смысл. Перед прекращением хранения старое поле убирают из LIST OVERVIEW.FMT. Новое добавляют только после восстановления согласованности: когда база перестроена либо когда прежние записи истекли и весь оставшийся набор создан уже по новой схеме.

Сервер может располагать некоторыми значениями и всё же не публиковать колонку. Это не отрицание данных, а отказ выдавать частичную коллекцию за однородную. Временное ограничение схемы защищает значение каждой будущей пустой ячейки.

Нет колонки и нет значения — разные утверждения

Когда текущее объявление включает поле, а соответствующее место в строке пусто, клиент может заключить: у этой статьи нет данного заголовка или метаданных. Именно согласованная база обеспечивает такой отрицательный вывод.

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

Метаданные сервера тоже имеют границы

Поля :bytes и :lines отличаются от авторских заголовков. Их вычисляет сервер; одноимённые строки, внесённые внутрь статьи, не должны приниматься за источник этих значений.

Однако собственное вычисление ещё не означает абсолютной точности. RFC 3977 фиксирует исторические различия в подсчёте байтов и предписывает клиентам не зависеть от идеального совпадения. Для строк тела определение строже. Известное происхождение показателя не устраняет пределы измерения.

Диапазон также описывает только доступный остаток. Результаты сортируются по номеру, удалённые статьи не возвращаются, пробелы в нумерации допустимы. Overview не восстанавливает исчезнувшее тело и не доказывает существование каждого номера.

Реестр параметров NNTP IANA регистрирует OVER как возможность поддержки сводки. Реестр подтверждает общий сигнал совместимости, но не современную распространённость и не конкретную производительность.

Быстрая таблица держалась на узком утверждении

Общий индекс перенёс повторный разбор заголовков на сервер и сделал просмотр групп практичным. Но его доказательная сила возникла из добровольного ограничения: публиковать можно лишь колонку, история которой покрыта одной правилом.

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

Источники