Кратко

  • ALIWEB передавала поставщикам информации выбор ресурсов для описания, но сбор данных и поиск оставались централизованными.
  • Пилот 1994 года показал, что небольшим индексом могли пользоваться другие каталоги; он не доказывает ни охват всего Web, ни широкое распространение сервиса.

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

30 ноября 1993 года Martijn Koster объявил ALIWEB экспериментом по «распределённой» индексации Web. Каждый сервер сообщал бы о своём содержимом в локальном файле; один сайт автоматически забирал бы и обрабатывал такие файлы; объединённую базу можно было бы искать через Web. В более поздней конференционной статье Koster писал, что пилот на веб-сервере NEXOR работал с октября. В объявлении от 30 ноября он называл ALIWEB первым шагом, а не окончательным решением, и обещал: данные должно быть легко использовать или преобразовать, когда появятся более удачные схемы.

Это обещание проясняет архитектуру. ALIWEB не децентрализовала саму поисковую службу; она распределяла контроль над индексом. Администратор сайта выбирал документы и службы, достойные записи, и составлял их описания. Оператор ALIWEB вёл список участвующих серверов, задавал интервалы получения файлов, проверял формат, объединял принятые записи и управлял поисковым интерфейсом. Поставщик описывал собственный сайт; центральная служба определяла путь, по которому это описание становилось доступным пользователям других сайтов.

Входными данными был подготовленный текстовый файл, часто /site.idx, основанный на шаблонах Internet Anonymous FTP Archives (IAFA). Записи в формате «атрибут — значение» могли описывать несколько объектов в одном файле: тип шаблона, заголовок, URI, описание и ключевые слова. ALIWEB не пыталась выводить значение каждой страницы из её разметки. Вместо этого люди, знавшие устройство сайта, выбирали важные точки входа и сохраняли внутреннюю структуру. В примере Koster описаны материалы NEXOR по Perl и руководство к ним, но не все файлы сервера.

Для участия требовалась небольшая операционная договорённость. Администратор указывал сервер, порт и путь к индексному файлу в веб-форме, оставлял контакт ответственного лица и мог задать минимальный интервал между получениями. ALIWEB проверяла наличие файла и его формат до регистрации. Отдельный процесс на Perl проверял зарегистрированные индексы, забирал изменённые версии и заново собирал базу по расписанию UNIX cron. Искать по ней можно было через простую форму ALIWEB или через другой каталог, включая CUI W3 Catalog.

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

Опубликованные Koster показатели показывают и использование, и границы системы. На момент статьи были зарегистрированы 54 хоста, а база содержала 310 записей. Простой поиск ALIWEB выполнялся в среднем 80 раз в день; CUI W3 Catalog обращался к базе более 8 000 раз в неделю. Эти цифры подтверждают работу сервиса и одно полезное подключение. Они не показывают долю проиндексированного Web, качество выдачи или число серверов, которые могли и хотели поддерживать корректный файл.

Проблемы регистрации проявились рано. Некоторые администраторы указывали хост, но не предоставляли индексный файл: по оценке Koster, они переходили к форме, ещё не понимая принципа работы. Команда расширила документацию и добавила немедленную проверку наличия и формата файла. Ошибки в индексах всё равно случались; система записывала их, а вручную запускаемый скрипт отправлял сообщение ответственному лицу. Децентрализация не отменяла сопровождение, а переносила его с обхода каждой страницы на подготовку, проверку и обновление выбранного индекса.

«Ручной» не обязательно означало, что каждую строку нужно было постоянно писать вручную. Koster допускал автоматическое создание файла, если в нём сохранялось достаточно метаданных для выбора результатов. В 1995 году другой архивный проект описал, как шаблоны IAFA обновлялись при изменениях файловой системы и превращались в текстовые, Gopher- и HTML-индексы. Эта статья конференции W3C показывает, что шаблоны могли обслуживать разные способы представления. Она не доказывает миграцию данных самой ALIWEB или широкое распространение службы.

Рост выявил вторую границу. Koster признавал, что единая база для всего Web может стать слишком большой. В качестве возможных решений он называл распределённый сбор, зеркальные точки доступа к поиску, тематические базы и иерархию служб ALIWEB. Он также ожидал, что индексные файлы можно будет автоматически преобразовывать для будущих каталогов. В статье это планы, а не внедрённые функции. Их исторический смысл в том, что формат задумывался как способный пережить центральный сборщик пилотной системы.

Обзор сетевого информационного поиска за 1994 год описывал эту область как молодую: классификация и другие возможности ещё не были широко распространены. ALIWEB работала рядом с ручными списками, CUI W3 Catalog и роботизированными системами вроде JumpStation и базы URL RBSE. Это не была первая поисковая система Web. Её более узкий вклад — демонстрация того, как описания, выбранные поставщиками ресурсов, можно собирать автоматически и использовать в других системах.

Поздняя Заметка 65 Heng Lu о первичности работающего кода даёт ретроспективную аналитическую рамку, но не свидетельствует о взглядах Koster: формат может обещать переносимость, однако она становится реальностью только при его принятии работающими системами. Статья подтверждает работу пилота ALIWEB и использование её базы каталогом W3. Она не подтверждает всеобщее принятие, право устанавливать обязательные правила для издателей Web или завершённую миграцию. Исторически важно различать три полномочия: поставщик решал, как описать собственный сайт; ALIWEB решала, что попадёт в общий индекс; будущая система могла использовать файл, не перенимая центральную службу пилота.