> Об этом проекте я знаю немного, видел только архивчик tbz2 на 700 МБ..
> Вопрос что хочется получить в дальнейшем, просто из того что я
> прочитал, вы не думаете, что получите больше проблем чем решите?
> Расскажите поподробнее, или на форуме, а то он какой-то мёртвый
> совсем.. Тогда можно будет конструктивно покритиковать :)
тут я еще накатал небольшой материальчик - может понятнее станет... Если
нет - задавайте вопросы:
Некоторым уже известен проект lindocs - проект offline документации по
linux и unix-подобным системам. Сейчас он переживает переходный период,
когда базой ссылок стало уже неудобно управлять и производить по ней
навигацию.
Сейчас база представляет набор html-файлов, в которых собраны ссылки по
схожим (или не очень) тематикам. Основным является файл begin.html, в
котором хранятся ссылки на файлы-тем - html-страницы отвечающие за одну
какую-то тему. А уже в из файлах-тем хранятся ссылки на материалы,
хранящиеся в lindocs.
begin.html
| / Linux/Sendmail/pages/lessons.htm
mail.html - Linux/Sites/opennet.ru/base/net/mta_chouse.txt
| \ Linux/Sites/Perm_doc/tune/28.12.1998.html
|
bd.html
|
general.html
|
| / Linux/Docs/pdf/Python.pdf
python.html - Linux/Programing/Python/whats_new_22.html
\ Linux/Docs/pdf/samag12832-0.pdf
Проблема в том, что один материал может попадать в разные файлы-тем, так
как в нем могут затрагиваться различные аспекты настройки и управления
системой. Например, материал освещающий настройку почтового сервера с
хранением базы пользователей в какой-нибудь СУБД с использованием
скриптов для автоматического управления этой связкой - в данном случае
материал должен появиться сразу в трех разделах: "настройка почты",
"базы данных", "программирование". При ручном управлении базой ссылок
пришлось бы добавить ссылку на этот материал в три html-файла, что
вызывает избыточность, а также неочевидность и сложность поиска
дублирующихся материалов при добавлении новых.
Поэтому возникла идея создать новый формат хранения ссылок (за идею был
взят способ организации архива документации на opennet.ru). Пусть помимо
информации о ссылках в базе данных хранится информация о категориях, в
которые может попадать тот или иной материал - назовем их индексами. А
сам архив ссылок изначально не будет разделяться на множество файлов -
вместо этого все ссылки с указанием того, к каким категориям каждая из
них относится, будут хранится в одном месте. База индексов в свою
очередь могут иметь иерархическую структуру для более логического
построения выходной информации.
INDEXES: mail, bd, programing, postfix, exim, fetchmail, mysql,
postgresql, perl, python, java
/ postfix / perl
mail - exim bd - mysql programing - python
\ fetchmail \ postrgesql \ java
При очередной публикации содержимого проекта lindocs эта куча ссылок
автоматически в соответствии с их индексами распределяется по множеству
html-файлов для offline просмотра документации.
Более подробно.
На текущий момент индексы можно получить из имени html-файла, в котором
упоминается тот или иной материал - этому материалу присваивается данный
индекс. В дальнейшем индекс у материала может быть изменен или даже
удален (материал без индекса также помещается в результирующую выборку и
помещается на основной странице проекта - так, например, очень удобно
следить за поступлением новых материалов). Чтобы не придумывать новые
индексы, которые будут использоваться для дальнейшей "продвинутой"
индексации, - можно использовать уже существующие в проекте opennet.ru:
индексы помещены в начале каждой статьи, оформленной как "*.txt", и они
легко получаются из этих файликов простым скриптом.
При чтении документации пользователь может изменить индексы относящиеся
к материалу:
1) заменить индекс, если материал подходит не для данной тематики, а для
другой
2) добавить индекс, если материал затрагивает не только одну тему
3) удалить индекс, если в материале не затрагивается данная тема
Плюс ко всему он может создавать также новые индексы для базы или
удалять существующие, если нет ни одного документа с таким индексом.
Также пользователь может добавлять и удалять (эту возможность нужно
оставить только для мантейнера проекта) материалы при работе с базой.
Все изменения коснувшиеся базы в локальной копии пользователя по его
желанию могут быть экспортированы в некторый "patch-файл". Этот файл
пользователь может передать мантейнеру проекта, для внесения изменения в
основную ветку проекта. И наоборот, мантейнер может передавать
сформированный patch-файл пользователям, для того чтобы те могли
поддерживать свои копии в актуальном состоянии.
Чуть-чуть о реализации.
У материала в базе должны быть следующие атрибуты: название, автор(ы),
относительная ссылка - место в файловой системе, абсолютная ссылка -
место расположения материала в Интернет, один или несколько индексов, а
также служебные атрибуты (идентификатор записи, номер части, если
материал состоит из нескольких частей и др.). Абсолютная ссылка нужна
для того, чтобы можно было говорить об online версии проекта - ресурса,
на котором пользователь мог бы найти место положение в Интеренте
интересющей его информации.
Индекс в базе тоже имеет атрибуты: описание (будет выводиться как тема
обобщенных материалов) и родитель (значение индекса, которое
непосредственно указывает подтемой какой темы является данный индекс;
например, postfix - mail, mysql - bd)
При получении конечной информации (html-файлов) следует учитывать, что
если среди индексов материала есть "дерево" - и индекс-родитель и
индекс-потомок (не важно какой вложенности), то материал помещается
только один раз в тему индекса-потомка. Например, некоторый материал
имеет индексы "mail", "procmail", "filter", а индексы соотносятся
следующим образом: дерево "mail" -> "procmail", и отдельно "filter" -
значит, материал помещается в файлы "filter.html", "mail_procmail.html",
но не в "mail.html".
Смежные темы могут быть также перечислены в конце каждого из итоговых
файлов в зависимости от тех дополнительных индексов которые не относятся
на прямую к данной теме. Так если мы говорим про уже рассмотренный
пример, то в конце файла "filter.html" будет иметься ссылка на
"mail_procmail.html", а в конце "mail_procmail.html" - ссылка на
"filter.html".
Отдельно имеет смыл говорить об специализированном программном
обеспечении для работы с базой ссылок. Его предназначение заключается не
только в том, чтобы можно было добавлять, удалять и изменять информацию
о индексах и материалах, хранящихся в lindocs, но и для организации
удобной навигации и быстрого поиска нужной информации в проекте.
Очевидно, что данное ПО желательно должно быть кроссплатформенным.
Можно предложить следующие связки для программирования интерфейса: Java,
Python+GTK, Perl+GTK.
Что же выбрать в качестве хранилища для базы данных ссылок (не для
материалов)? Можно рассматривать как варианты:
1. XML
2. SQLite
О каждой поподробнее.
XML. Популярный формат хранения данных. Информация в нем при правильном
подходе хорошо структурированна. Имеет готовые средства для обработки
данных хранящихся в нем - удобно для построения выходных файлов. Но как
минус, как-то невнятно реализованы средства добавления, изменения и
удаления информации, хранящейся в данном формате. Хотя, так как XML по
сути простой текстовый файл, то изменять информацию в нем (в случае
чего) можно в текстовом редакторе. Также доступны специализированные
редакторы XML-файлов.
SQLite. "Это безтиповая, безсерверная (нет процесса-демона,
обрабатывающего запросы клиентов) СУБД, с поддержкой транзакций,
блокировок, триггеров, полного синтаксиса языка SQL92." Вся информация
базы данных хранится в одном файле специального формата. Работа с этим
файлом происходит на SQL-языке с помощью подключения специальных
библиотек (уже существующих для всех популярный языков программирования,
возможно даже выполнение SQL-запросов прямо из shell-скриптов). В
отличие от других СУБД с ним не нужно дополнительных плясок при переносе
базы в другое место. Как минус следует отметить необходимость
использования специального ПО для работы с базой.
Итак, подведем итог. Так как c XML плохо производить такие действия как
удаление и модификация, то в качестве БД можно использовать SQLite, а
XML использовать для хранения и перемещения изменений между разными
копиями проекта.
