Будущее gopher

В настоящее время раздается много голосов, которые уверяют, что время Gopher прошло. Но сообщество Gopher не сдается. На ежегодных конференциях Gopher разработчики докладывают о новых направлениях исследований и разработок, направленных на совершенствование системы и повышение ее потребительских качеств. Главные заботы разработчиков программного обеспечения связаны со следующим кругом вопросов:

• поддержка связи и полноценная поддержка World Wide Web страниц

• повышение изобразительных средств системы

• разработка мощного поискового аппарата

• разработка новых систем, которые обеспечивали бы поддержку старых баз данных Gopher.

Своеобразным ответом на вызов World Wide Web стала система Gopher+. В данной версии Gopher реализована возможность работы по протоколу Gopher со страницами Web. Система отрабатывает гипертекстовые ссылки и позволяет клиентам правильно работать с HTML-документами. Таким образом, упреки в том, что Gopher не обладает достаточными изобразительными средствами, недостаточно обоснованы.

Но разработчики новых поколений Gopher-software пошли дальше. В системе Blue-Skies Gopher было реализовано нечто похожее на механизм графических гипертекстовых ссылок, что позволило включить в навигационную систему Gopher и графику. Кроме этого, в силу простоты самого Gopher, разработчики серверов системы задумались и о расширении возможностей поискового аппарата системы. Veronica - это только первая ласточка информационно-поисковых систем на базе Gopher, которые призваны облегчить ориентировку пользователя GopherSpace. Главным направлением здесь рассматривается возможность применения методов кластеризации документов и уточнение результатов поиска по обратной связи. Оба этих подхода хорошо известны по обычным информационно-поисковым системам, наподобие тех, что использовались для ведения баз данных реферативных журналов ВИНИТИ. Более того, в качестве прототипа поисковых средств были выбраны средства информационно-поисковой системы SMART Корнельского университета, которая разрабатывалась под руководством Дж. Селтона в конце 80-х как исследовательский проект для будущих поколений информационно-поисковых систем.

Однако наиболее радикальные решения предложены в другом проекте распределенной информационной системы - Hyper-G. Из всех систем, затрагивающих будущее Gopher, - это, пожалуй, наиболее кардинальная ломка концепции системы и расширения ее возможностей. Сама концепция была высказана Кэпом в 1993 году. В это время Gopher получил наибольшую популярность в Internet, и его разработчики стали задумываться о будущем системы. В 1994 Маурер и Эндрюс опубликовали первое описание системы. Главная задача данного проекта - разрешить ограничения Gopher и World Wide Web и на их основе построить новую распределенную информационную систему. В качестве слабых мест назывались:

• ручная генерация ссылок

• потеря ориентации в пространстве гипертекстового графа

• потеря целостности системы при перемещении ресурса

• трудности, связанные с администрированием большого количества формально не связанных документов

• ограниченные поисковые возможности.

Для преодоления этих недостатков разработчики предложили несколько принципиальных изменений в архитектуре систем.

Для обеспечения полномасштабных сеансов работы пользователей с информационными ресурсами распределенной информационной системы предлагалось перейти от протокола без установки долговременного соединения к протоколу с установкой долговременного соединения. Это означало, что работа с системой будет вестись так же, как в telnet-сессии или при просмотре новостей Usenet. Такой подход дает то преимущество, что понятие сессии взаимодействия с системой расширяется до возможностей обычной локальной информационно-поисковой системы или системы управления базами данных. Если в настоящее время весь сеанс работы в World Wide Web или Gopher состоит из запроса на ресурс и ответа на этот запрос, то в новой системе в течении сеанса таких запросов можно сделать много, и при этом можно управлять контекстом сеанса, а также запоминать состояние сеанса для рестарта. Такой подход освобождает от проблем программистов, разрабатывающих интерактивные CGI-скрипты, для которых хранение результатов предыдущих сессий является настоящей "головной болью", усложняющей структуру документов, форм и самих скриптов.

Вторым ключевым моментом является переход к системе распределенных баз данных, которая похожа на систему распределенных серверов Usenet. В этом случае пользователь реально работает только с ближайшим сервером Hyper-G и не ждет доступа к ресурсу, расположенному за тридевять земель. При этом он работает не с ограниченными ресурсами локальной базы данных, а со всем множеством документов системы, которые циркулируют в сети Hyper-G.

Проблему перемещения ресурса предполагается решать за счет применения не универсального локатора ресурса, как это делается в World Wide Web, а за счет универсального имени ресурса - URN. Собственно, URN - это расширение концепции URL. При использовании URN не требуется знать, где конкретно расположен ресурс, а надо знать только его уникальный идентификатор, поэтому перемещение по сети не должно вызывать проблем у пользователей, как это происходит в настоящее время.

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

Все перечисленные возможности, решая одни проблемы, порождают одновременно другие. При on-line-сеансе возникает проблема одновременного обслуживания пользователей. Система не в состоянии обеспечить всех желающих доступом к информационному ресурсу. Здесь разработчики видят два выхода: первый можно назвать "время и деньги", а второй "публичная библиотека".

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

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

Естественным продолжением в дисциплине обслуживания пользователей является система навигации в Hyper-G. Здесь предлагается позаимствовать традиционную систему иерархий Gopher и систему встроенных гипертекстовых ссылок World Wide Web, дополнить эти механизмы методами кластеризации и ввести механизм репликации. О кластеризации речь шла выше, а на репликации стоит остановиться более подробно.

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