Ответ на письмо от 09.08.2004
Здравствуйте, Саша,
Здравствуйте, господа.
Заранее хочу сказать, что я не смогу принять участие в работе, а могу
только участвовать в обсуждении. Я не собираюсь продавливать и
защищать свои предложения. Я лишь высказываю свою точку зрения, и даю
свои ответы на вопросы, которые могут иметь множество ответов.
Чем мне не нравится нынешняя дискуссия о каталогизации, так это её не
структурированностью. Так серьёзные дела не делаются. Нет, если кто
хочет изобретать велосипед своей собственной конструкции и со своими
функциями, то я лично только ЗА! Для собственного развития это может
оказаться очень полезным. А вот продукт вряд ли получится.
Я бы хотел предложить упорядочить обсуждение, насколько это возможно.
Первым делом надо поставить задачу. А то название <<Каталогизация>>
можно понимать очень по-разному, что и демонстрирует настоящая
дискуссия. Тут ведь в чём проблема? Энтузиасты всегда найдутся, и вот
они уже начинают что-то даже макетировать, но единого-то понимания
нет! Давайте же сначала договоримся - Что мы собираемся делать, а уж
потом каждый решит, а захочется ли ему это делать, и не лучше ли
делать нечто своё.
Второй вопрос - на кого рассчитан результирующий продукт. Сюда
включается и уровень подготовки пользователя и платформа
использования. Вот тут уже конкретные инструменты предлагаются, а,
по-моему, это забегание вперёд паровоза. То же самое можно сказать и о
предложении конкретных форматов и структур данных. Без ответов на
первые два вопроса это суть необоснованные сотрясения воздуха и
электрических сетей.
Третий вопрос - инструменты программирования и форматы данных.
Четвёртый вопрос - кто и как всё это будет делать? После решения
первых трёх вопросов, я очень надеюсь, останутся желающие это
реализовать. Надо выбрать ответственных координаторов работы и
поручить им руководство добровольцами программистами.
Решение этих четырёх вопросов должно быть зафиксировано в Техническом
Задании. Без этого мы сильно рискуем вернуться к классике - смотри
Крылов <<Квартет>>.
* * *
Теперь я предложу свои ответы на поставленные вопросы.
Постановка задачи.
Дано:
- Коллекции книг в разных форматах на компьютерах отдельных пользователей.
- Коллекции книг в разных форматах на Интернет-сайтах, ftp-свалках и т.п.
- Люди, желающие обмениваться книгами.
- Люди просто ищущие конкретную книгу.
Цели проекта:
- минимизация времени и сил пользователя для поддержания своей
коллекции книг.
- повышение эффективности поиска книг в своей и чужих коллекциях.
Задача.
Создать технологию и для обеспечивающую следующие функции:
F1. Эффективный, удобный и быстрый поиск книг/книги по имеющимся коллекциям.
F2. Обмен информацией между различными коллекциями.
F1 подразумевает (согласно данным условиям) поиск как в локальной
коллекции, так и в чужих коллекциях. Отсюда вытекают, по крайней мере,
три функции:
F1.1. Поиск по локальной коллекции книг.
F1.2. Поиск по чужой (внешней) коллекции книг.
F1.3. Поиск по Интернет-коллекции книг.
ЗАМЕЧАНИЕ. В данной постановке сразу отсекается вопрос о чтении книг,
а, следовательно, и о читалках. Эту совершенно самостоятельную функцию
можно рассматривать как дополнительную, скажем, включить её в раздел
прлагинов. Или же разрабатывать более масштабный комплекс, куда
включить каталогизатор и читалку как самостоятельные подсистемы
интегрированного пакета.
Каталог книг суть информационная структура данных для обеспечения
вышеуказанных функций. Каталогизатор суть средство работы с каталогом.
Он должен обеспечивать следующие функции:
FK1. Автоматизированное создание каталога книг из локальной коллекции.
FK2. Добавление книги, как ручное, так и автоматизированное.
FK3. Обновление информации о книге, как ручное, так и автоматизированное.
FK4. Удаление книги.
FK5. Экспорт каталога.
FK6. Импорт каталога. (необязательно)
Какую информацию хранить в каталоге, и как её структурировать? Этот
вопрос не столь очевиден. Например, можно взять любую библиотечную
систему, и ничтоже сумняшися, все поля перенести в наш каталог.
Избыточность полей и информации будет чудовищной, но, в общем-то,
мегабайтом больше или меньше, - вопрос не существенный (ведь в
постановке задачи мы не упоминаем экономию дискового пространства).
Однако мне такой подход не нравится. Я полагаю логичным, исходить не
из функций обычных библиотек, - для которых и делались все
библиотечные системы, - а из заявленных функций нашей гипотетической
системы. Достаточно очевидно, что они различаются.
Например, вопрос о разделе, теме книг. С библиографической точки
зрения можно содержательно дискутировать: как правильнее
атрибутировать <<Преступление и наказание>> Ф.М. Достоевского -
классика; русская литература IXX века, детектив, психологический роман
и т.д и т.п. По-моему, достаточно очевиден простой факт, что каждый
может отнести книгу к любой категории, к какой ему заблагорассудится.
Не столь очевиден, - но у меня не вызывает никаких сомнений, - факт,
что древесная структура данных не может покрыть проблему тематики или
категоризации книг. Книга может принадлежать к разным категориям,
иерархия которых совершенно не предопределена. Те, кто хранит книги в
директориях по теме, меня поймут, - очень непросто бывает разместить
новую книгу в уже имеющуюся структуру. Теперь посмотрим на это дело с
точки зрения обеспечения заявленных функций. На кой ляд нам ломать
голову над вопросом, куда нам положить книгу на диске? Структура
файлов имеет значение только при первичном сборе информации. Для
поиска, кроме Автора и Названия, нам нужны просто ключевые слова,
безотносительно к жанру, теме, и прочим категориям. Как хранить
ключевые слова - вопрос чисто технический. Но не кажется ли вам,
уважаемые коллеги, что такой подход облегчит жизнь и тем, кто ведёт
библиотеки, и тем, кто ими будет пользоваться? А на <<правильности
решения по существу>> можно не зацикливаться.
FK1. Подразумевает установку программного обеспечения и сбор
информации о локальной коллекции книг. Очевидно, что способ хранения
книг критичен для этой подзадачи. Мне представляется разумным заложить
сюда два свободных параметра: 1) формат хранения книги; 2) файловая
структура коллекции книг. Сборщик информации должен зависеть от этих
двух параметров. Мне кажется, надо проанализировать имеющиеся файловые
структуры, определить приоритетные, и именно с них и начинать
реализацию. Наверное, наиболее логичным решением будет делать плагины
под каждую файловую структуру. Обработка конкретного формата каждой
книги тоже, по-моему, разумно сделать как плагины, для txt-DOS свой
плагин, для chm свой. Сборщик должен уметь выдирать из книги Автора и
Название.
FK2 - FK6 мне сейчас лень рассматривать.
Для кого же предназначен наш гипотетический каталогизатор? Первый
ответ очевиден: для тех, кто уже нахлебался с ведением своих
библиотек. Мы, так сказать, делаем это для себя любимых. А поскольку
люди мы - не чайники, то и позволить себе можем всё вплоть до
технологии клиент-сервер, лишь бы полученный продукт нас удовлетворил.
Именно с такой позиции сейчас многие и выступают. Я не спорю, можно и
так делать. Но мне ближе другая точка зрения. Я бы ориентировался на
две категории пользователей: 1) те, кто ведёт свои библиотеки; 2) те,
кто ищет конкретную книгу.
Собственно, это и приводит меня к функциям обмена каталогами и/или
центрального каталога. Это же, на мой взгляд, во многом предопределяет
выбор инструментов. Для начала я, напомнив, что мы делаем поисковую
систему, отвергну варианты каталогов тестового типа, - txt, doc, html,
xml и т.п. Функция поиска, по-моему, просто-таки диктует использование
баз данных. Ведь чем поиск по тексу отличается от поиска по базе? При
поиске по тексту ты получаешь очередное, но одно (!) значение, а в
базе данных - набор записей удовлетворяющих условии поиска. Я бы
поставил xml несколько особняком, там действительно можно сделать базу
данных. Но ведь СУБД имеет Систему Управления Базами Данных, а для xml
есть только полуфабрикаты разбора и представления. Смешно сравнивать
готовый сервис СУБД с этими приблудами. Это касается
внутрипрограммного ядра. Однако, кто же нам мешает выдавать
пользователю различные варианты каталога для работы? И txt, и html, и
xml представления элементарно генерируются по базе данных, так что,
совсем необязательно навязывать пользователю интерфейс нашей
программы.
Не важно линукс или виндоуз, но каталогизатор должен иметь минимальные
неудобства для пользователя. Я не хочу сейчас вдаваться в технические
подробности, но Дельфинам хочу напомнить, что навязывать установку BDE
просто неприлично. Чего стоят заморочки с разными версиями этого
энджина многим известно. Против самого Дельфи я ничего не имею.
Первой очевидной дилеммой является Windows или Linux? Для крутых
специалистов, вероятно, Линукс. А если исходить из наиболее широкого
круга конечных пользователей, то однозначно виндоуз. Но, на мой
взгляд, самым правильным решением было бы включение в проект обеих
платформ (кажется, уже есть желающие делать и на той, и на другой).
Значит базы данных. Под виндоуз я бы лично тоже выбрал эксессные
mdb-файлы. Обращаю ваше внимание, что нам понадобится только mdb-файл,
а отнюдь не платный MS Access. Оболочку можно писать на чём угодно,
этот выбор можно оставить за самими исполнителями. Надо только
оговорить неприменение монстров типа BDE или Microsoft SQL Server. Под
Линуксом я бы лично не стал заморачиваться с серверами типа MySQL и
PostgeSQL. По моему это стрельба из пушки по воробьям. Крайне странно
было слышать, что любая база нуждается в установке сервера. Куча
небольших программ пользуются базами без этого. Например,
небезызвестная AIDA32 использует mdb, я не говорю уж о dbf-файлах. В
виндах хорошо то, что SQL-engine уже встроен в них, и не требует
никаких специальных установок.
Очень важной мне представляется функция обмена каталогами между
машинами. Тут, прежде всего, встаёт вопрос: попарный обмен или
центральный каталог? Делать можно и так и так. Я - за центральный
каталог. Вот некоторые аргументы.
- Мне проще один раз сбросить свой каталог в центральную базу, чем высылать его
каждому желающему.
- Искать конкретную книгу эффективней, конечно, по центральному каталогу.
- Центральный каталог, как мне представляется, идеальное место для размещения
ссылок на книги в Интернете.
- Центральный каталог позволяет модерировать книжный обмен. Участников можно
рейтинговать по отказам или обманам.
- Центральный каталог позволяет использовать механизмы стимулирования и ограничения
а-ля классические BBS, буде возникнет такое желание (а оно таки может возникнуть
при большом количестве пользователей).
Мне видится вот какая технология.
В Интернете стоит сайт с центральным каталогом. По нему Пользователь
может искать конкретные книги. Эти книги могут оказаться либо в
Интернете, либо в частной коллекции. В последнем случае пользователь
может направить <<заявку>> на конкретную книгу. Письмо генерируется
сервером так, что пользователь не видит реального имэйл-адреса. А
<<заявка>> содержит адрес пользователя.
Каталогизатор может импортировать текущий каталог. Этот каталог должен
содержать имя и пароль зарегистрированного участника проекта. Этот
каталог либо автоматически из оболочки каталогизатора, либо в ручном
режиме закачивается на сервер, где по расписанию производится
автоматическое обновление центральной базы.
Возможно, это не совсем то, что вы собираетесь делать, я не настаиваю.
Но предлагаю задуматься КАК делать.
