[еКнига] Каталогизация : продолжение

Здравствуйте, Саша и остальные участники листа!

Очень рад, что опять поднята эта актуальнейшая тема! В части
программирования и т.п. пока ничем помочь не могу. Готов участвовать
собственно в заполнении базы.

Так я отвечаю на ваше письмо от 9 августа 2004 г.,
на тему [еКнига] Каталогизация : продолжение.
где вы писали:

Потом. Думаю,будет хорошо сделать.....э...как бы объяснить.....Ну,короче,будет
4 раздела (Художественная литература,Научная литература,Справочная литература,Разное
- кто не согласен,предложите свои разделы).

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

Дык вот,это ,скажем так, первый уровень
.Второй - это,наверное,жанры.В художественной - это фантастика,детективы,любовные
романы и прочее.Начуная литература - это может быть учебная литература,кукбуки,покет
буки(карманные книги,вроде). И так далее.

Не понял, о чём тут... Думаю, что научную литературу и нужно делить по
наукам, тут можно предложить 4 раздела - точные, естественные,
социальные и гуманитарные науки, а также междисциплинарные науки.

Это второй уровень. Третий уровень
- на усмотрение пользователя. Первый уровень задан жёстко,второй и третий - на
усмотрение пользователя.

Вообще же хотелось бы, чтобы в программе пользователь полностью мог
задать структуру самостоятельно. Если же начнём создавать базу для
общего пользования, например, для распространения на CD или для
выкладывания в и-нет, тогда можно будет обсудить структуру подробнее
здесь и выработать некий стандарт. Можно также попробовать
воспользоваться какой-нить официальной классификацией, например, ББК
или УДК.

Что же касается полей, то думаю, наиболее необходимыми являются Автор,
название (единственное абсолютно обязательное поле) и тема, Имя файла
- вряд ли столь уж обязательно, ибо ведь книгу можно будет открыть
непосредственно из базы, правда? Впрочем, мне кажется, что в идеале
должны быть две формы представления данных - краткая (автор, название,
тема), и полная, когда выводится полное библиографическое описание,
сведения о файле, и вообще вся информация, которую составитель базы
почёл за нужное внести при добавлении книги. Скажем сделать ряд полей
скрытыми по умолчанию и выводимыми только по команде пользователя.
Кстати, добавление инфы о файле (название, размер, дата и пр.) неплохо бы было
сделать
автоматической. Ну я замечтался, кажется... Очень уж нужна такая
программа!

Здравствуйте, все!
Хочу присоединиться к дискуссии про
чудо-программу... Сначала пару слов о базах данных. Если при разработке
использовать одну из сред программирования от Борланда (Delphi/c++builder),
то ненадо ставить никакого сервера. Для работы на пользовательскую машину
надо установить файл BdeInst.dll после чего можно в своих проектах
использовать SQL запросы в компоненте TQuery.
Во-вторых. Не понял проблему с количеством тем. Откуда такое строгое
ограничение???!!! Кроме того, имеет смысл задуматься над тем, будет ли
интерфейс иметь вид обычной таблицы или его лучше оформить в виде дерева...
И наконец. Для себя я написал маленькую утилиту для каталогизации любых
книг. Правда, она основана не на базах данных, а на текстовых файлах. Проще
говоря, моя база хранится в текстовом файле, и я сам написал функции по его
обработке. Моя база имеет 4 поля: "Катигория", "автор/источник", "Название
книги", "Имя файла". Интерфейс оформлен в виде трёх комбинированных списков,
каждый из которых соответствует трём первым полям. причём, когда в первом
списке я выбираю интересующую тему, второй и третий автоматически
прокручиваются на имя автора и название первой книги в этой теме.
Аналогично, когда я выбираю автора во втором списке, то первый
прокручивается на название темы к которой этот автор относится, а третий --
на название первой книги этого автора. Но это ещё не всё... Когда книга
выбрана, можно нажать "enter", и книга откроется тем приложением, которое
сопоставлено данному расширению. Так что ограничения на просмотр связаны
только с наличием или отсутствием нужной программы в системе.
Алексей.

--
Дискуссионный лист "Электронная книга"
Модератор - Михаил Духонин <mihail_***@m*****.ru>
Перед вами 2504 выпуск листа, разошедшийся для 662 человек.
Постоянный адрес выпуска этого письма в архиве -
http://subscribe.ru/archive/lit.book.library.ebookaccess/msg/208887

-*Информационный канал Subscribe.Ru
Адрес подписки:
Написать в лист: mailto:lit.book.library.ebookaccess-list@subscribe.ru
Отписать: mailto:lit.book.library.ebookaccess--unsub@subscribe.ru

http://subscribe.ru/ http://subscribe.ru/feedback

Здравствуйте, Alexey Bazarov и остальные участники листа!

Так я отвечаю на ваше письмо от 10 августа 2004 г.,
на тему [еКнига] Каталогизация.
где вы писали:

Кроме того, имеет смысл задуматься над тем, будет ли
интерфейс иметь вид обычной таблицы или его лучше оформить в виде дерева...

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

P.S. Мыслю как незрячий пользователь компа. Очень уж противно слушать
обрезанные записи... Для примера см. буксир или оболочку для
"библиотеки в кармане".

Ответ на письмо от 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, буде возникнет такое желание (а оно таки может возникнуть
при большом количестве пользователей).

Мне видится вот какая технология.

В Интернете стоит сайт с центральным каталогом. По нему Пользователь
может искать конкретные книги. Эти книги могут оказаться либо в
Интернете, либо в частной коллекции. В последнем случае пользователь
может направить <<заявку>> на конкретную книгу. Письмо генерируется
сервером так, что пользователь не видит реального имэйл-адреса. А
<<заявка>> содержит адрес пользователя.

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

Возможно, это не совсем то, что вы собираетесь делать, я не настаиваю.
Но предлагаю задуматься КАК делать.

Здравствуйте Владимир,

Friday, August 13, 2004, 7:18:27 PM, вы не поленились и написали:

Значит нужне лидер. Чел, более или менее шарящий в программировании. И
готовый руководить и писать. Смелее товарищи. Выдвигайте кандидатуры.
Пусть он и руководит обсуждением. А-ля: ставит вопросы, подытоживает.
Поможем. Эта штука нужна.

Линукс - программистов тут не слышно. Только делфятники. Да и давайте
трезво мыслить - винда пока превуалирует.
НА кого рассчитан - на человека, умеющего пользоваться электронной
почтой. Все остальное можно найти в документации.

ДАвайте голосовать, что ли.
База данных vs XML-файл.
Только аргументировать. Только аргументом не признается то, что "вот я
тут начал изучать базы данных, давайте их и будем юзать"

Пусть они сами изъявят желание. А ведь есть же модератор, тот чел,
который создал этот лист. Пусть и руководит. Все-равно всякой фигней
занимается :))

Я бы сказал главная вещь при написании любой проги.

А я предлагал сделать обмен инфой об своей коллекции через веб-сайт. И
не обязательно один. Можно сделать несколько сайтов. Любой может
начать это дело и хранить у себя на сайте инфу о коллекциях. И в проге
это должно быть прозрачно - подключаемся к такому-то узлу.

Согласен.

Я так полагаю наверняка есть классификаторы. Уж чего-чего а ГОСТ'ов
наше государство выпускать умеет много. Всяких ОКАТО и ОКУД развелось.
Может у кого есть доступ. Ведь каждый год ГосСтандарт выпускат
классификаторы.

Не шибко понял о чем вы. Нам не важно где и как хранятся книги. Нам
надо и добавить либо удалить из коллекции. А вот заниматься переводом
из одного формата в другой - сами сказали плагин. Второе совсем
туманно.

Это почему это базы так вот сразу. Поисковая система будет НЕ по
тексту книги, а по ее отдельным аттрибутам. Единственное преимущество
базы в том, что если вдруг каталог разрастется, то держать в памяти
его целиком (что предполагалось при использовании XML) не разумно. И
памяти может не хватить.

А зачем пользователю эти варианты представления. Он хочет только знать
- есть книга или ее нет.

Во-во.

Я тоже. И на самом деле преимуществ еще больше.

И не один. Человек может подключать другие, с таким же ПО.

НЕ так. Вы забыли про таких как я диалапщиков. Получается весь обмен
сводится к отправке по почте книг. Это не всегда удобно. Можно
предусмотреть возможность выбора: по мылу, или прямое скачивание.
Прямо с клиента. Минуя сервер. Либо(!) если у человека есть доступ к
анонимному фтп, с правами доступа для всех желающих он может
предложить этот адресок. Либо поступать как на weblife.ru (или
где-там еще) и давать место для загрузки книги. Это если только на нее
большой спрос. И время хранения ограничивать.

Правильно. Обсуждать надо. Давайте обсуждать.

Best RegardZ, |\-/|
<DeaD> |< R [] |_ I |< Отвечать сюда: dim84 |* *| onego.ru
\-/

--
Дискуссионный лист "Электронная книга"
Модератор - Михаил Духонин <mihail_***@m*****.ru>
Перед вами 2557 выпуск листа, разошедшийся для 660 человек.
Постоянный адрес выпуска этого письма в архиве -
http://subscribe.ru/archive/lit.book.library.ebookaccess/msg/211265

-*Информационный канал Subscribe.Ru
Адрес подписки:
Написать в лист: mailto:lit.book.library.ebookaccess-list@subscribe.ru
Отписать: mailto:lit.book.library.ebookaccess--unsub@subscribe.ru

http://subscribe.ru/ http://subscribe.ru/feedback

Добрый вечер, Dead.

Вы писали 13 августа 2004 г., 20:59:45:

В таком случае, в программе должна быть заложена возможность загрузить
и программное обеспечение для чтения экзотик-книг.

И где эту книгу можно взять.

Абсолютно ЗА. Даже двумя руками, и остальными конечностями :)))

Все же кажется, что один каталог должен быть главным, а остальные -
как зеркала.

А вот это мне кажется не требуется. Наоборот, в каталоге на сайте
(хранилище ссылок) необходимо (по моему мнению) подключить рейтинг
книг (по крайней мере отслеживать, какие книги наиболее часто
спрашиваются) и их как раз и выкладывать в свободный доступ. А
ограничение, это как-то....

Давайте, только люди слабо подключаются к обсуждению :(

Здравствуйте, мистер Дохлый Кролик, :-)

Это было бы здорово. Жаль пока что-то не видно.

Ну, MySQL и PostgeSQL это ориджинали порождения линукса.

Голсовать по моему рановато. А вот объявить дэдлайн для дискусии
вполне можно. И сделать это должен, скорее всего, модератор.

Согласен. Только не надо сразу голосовать и категорически
высказываться. Давайте послушаем аргументы друг друга. А уже после
примем решение (каждый своё), и проголосуем.

И впрямь :-) Михаил, не возьмётесь ли? Уверяю вас, чтобы руководить
работой программистов совсем необязательно быть программистом.

А смысл нескольких сайтов в чём? я не очень понял.

Мне-то как раз кажется, что нам на эти госты внимание обращать не
стоит.

Формат хранения - это txt, html, xml, pdf, doc, rtf, и прочие форматы
файлов. Всё это может, и, скорей всего, доожно быть заархивировано.
Представьте себе, что у вас на диске уже лежит несколько сотен или
тысяч книг. Их надо занести в каталог. Как? каждую ручками? Мне
кажется, что каталагизатор должен уметь собирать основную информацию
автоматически. Например. Я говорю каталогизатору, что у меня структура
директорий такая \раздел\тема\автор\книга, и он собирает инфу для этой
структуры. Или может быть в директории лежит файл описания конкретной
структуры, как на дисках библиотеки в кармане.

Да, это действительно не важно при уже наполненом и поддерживаемом
каталоге. А вот при первичном наполнении это очень важно.

Я эту функцию вообще не рассматривал, и считаю, что она далеко выходит
за рамки каталогизации.

Не согласен. Поиск нужен и по отдельным аттрибутам, и по нескольким
аттрибутам. Аргумент о памяти мне не кажется убедительным. Можно и
виртуальную память использовать. С моей точки зрения важнее другое. Вы
как-то проигнорировали мой аргумент по поводу представления результатов
поиска. Я-то полагал, что его одного достаточно, ну а если нет, то вот
другие аргументы.

- писать программу поиска и писать SQL запросы принципиально различное
по трудоёмкости дело. Конечно SQL быстрее написать.
- SQL даёт бОльшую надёжность. Самодельные программы поиска надо
отлаживать и тестировать, на что уйдёт масса времени. Я имею в виду
оптимизированные поиски, систему индексации и прочие в СУБД уже
готовые вещи.
- изменять структуру данных в базе данных несравнимо проще чем в
самодельной программе. Вряд ли разумно писать ещё и конвертор из
одной версии каталога в другую.
- Вообще, картотеки и каталоги - это именно те задачи, для решения
которых СУБД и создавались. И, мне право, как-то неловко это
доказывать. Я же не спорю, всё что угодно можно и на ассемблере
написать. И при грамотном подходе продукт при этом получится эчень
эффективный. Вопрос только в целесообразности инструментария и в
эффективности решения, повторяю, эффективности не продукта, а
его создания, поддержки и развития.

Дело в том, что разным людям удобнее работать с разными видами
представления информации. Кому-то подавай всё в платформонезависимом
HTML, кто-то без вёрда жить не может. Не стоит сразу заганять всех в
один интерфейс. Основной интерфейс должен быть. Но и эти представления
не сложно сделать. Впрочем, я не настаиваю.

Простите, не очень понял - вы таки за большевиков или за коммунистов?
Как это у вас уживается поддержка центрального каталога с разными
сайтами с одним и тем же ПО?

Не уловил вашу мысль, при чём здесь дайлап?

Нет, этого я не говорил. В центральном каталоге (равно как и в
локальном) могут быть ссылки на книги в инете - качайте.

Не понимаю. В центральном каталоге сами книги не хранятся. О каком
скачивании вы говорите? с компьютера владельца книги? Это мне
представляется крайне проблемотичным.

Да, с ftp и постоянными страничками всё ясно. Для этого ссылки и
предлагались.

А как вы себе представляете создание и поддержку краткосрочных ссылок?
Это очень интересный вопрос. СтОит подумать.

Доброе время суток, Владимир,

Угу... причем у PostgeSQL нет прямого порта под винду.

Моё предложение:
Приложение под windows, база данных в виде файла (примари - mdb, может
быть и XML, но что-то вроде xmlns:rs='urn:schemas-microsoft-com:rowset')
Структура основной таблицы - примерно то что я вбрасывал.
Скрин примерно тот, который я вбрасывал,
только менюшки побольше и функционал понавороченней...
Привернуть экспорт в XML (но своё пространство имен и строгий DTD)
Связать XML через XSLT и публиковать их пАрами.
(XSLT такая штука, которая при просмотре XML может показывать нормальную
красивую веб-страничку прямо в браузере, т.е. XML+XSLT=HTML)
Может даже порционные файлы XML (по разделам), чтоб снизить размеры частей.

ну или вариант с PHP на сервере:
upload этих самых xml-файлов.
публикуются данные по книгам и ссылки на располагающего книгой
(http, email, ftp, icq)

Выкладывать на сайт можно также и mdb-файлы.
причем там должна быть внутри инфа о владельце
(поддерживается в программе).

СИБИД страшная штука. Лучше не надо...
А есть ещё RUSMARC,
как-то я его смотрел и должен сказать, что это вообще
ходячий кошмар.

Дело в том, что загрузка из действительно большого XML файла и поиск по нему
будут заметно медленнее чем обращение к БД любого вида.

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

Доброго часу Все,

Вот тока-тока получил письмо модератора о закрытом листе. Но блин меня
выходные не было. Хочу выступить. Мне тута отвечали, позволю и я ответить.

Отвечаю на письмо Владимира.

Так меня уже называли. Что-нить веселее надо. Вроде 34 килограмма
диетического мяса :))

Смысл в том, что некоторые не захотят (как всегда) со всеми делиться.
А значит захотят сделать свои каталоги. Благо я думаю рабочий
интерфейс скрывать не будем.

Госты, на то и госты, чтобы на них обращать внимание.

Центральный в смысле локальный. Наверху ответил. ПО закрывать не
будем.

А если у меня дома есть, и нигде блин нету. Я сам лично отсканировал
(правда вот сканера нету, но не в этом суть.) И я хочу поделиться. И
не могу выложить. Да и не хочу. Может продавать хочу.

В чем проблема. Лично я не вижу никакой. Соединяются с головным
сервером. Сообщают свои ip-адреса. Передают книги.
Главное, что бы написано было нормально. В плане того, что бы легко
было фаер настроить.

Отвечаю на письмо Натальи Ульяновой

Да ничего чисто профессионального. Общие слова и все.
Ты пойми. Мы как люди более или менее в этом шарящие хотим продукт под
себя. То, что программу пишет один человек - плохо. Всегда.
Я не недооцениваю автора этой программы, просто мы сделаем так, как
нам надо. А ведь захочется нам чего-то большего. Автора что ли будем
просить. Ну попросим. Сделает через месячишко. Нас это не устраивает.
Чем больше людей, тем больше будет всяких полезных вещей в проге.

Отвечаю на письмо Красного Дракона

Не масштабно мыслите. Ерундой влюбленные занимаются, а у нас люди
серьезные. Вы себе представляете работу с форматом xls? Я лично нет.
Вы любите Total Commander - флаг в руки. Но открывать консервную банку
зубами - не наш метод.

Линукс тоже как-то слабо начинался. А ведь дорос до серверной
операционной системы.

И на второе его письмо

Не нравится не ешьте. Те кому надо, заказывают здеся книги. С одной
стороны засрали, извиняюсь, лист. Но с другой стороны не стоит
смеяться над нами.

Отвечаю на письмо Xammer'а.

Я могу взять на себя ответственность работы над этим движком. Делать
из форума - не есть гуд. Он не для того сделан.

Best RegardZ, |\-/|
<DeaD> |< R [] |_ I |< Отвечать сюда: dim84 |* *| onego.ru
\-/

--
Дискуссионный лист "Электронная книга"
Модератор - Михаил Духонин <mihail_***@m*****.ru>
Перед вами 2590 выпуск листа, разошедшийся для 657 человек.
Постоянный адрес выпуска этого письма в архиве -
http://subscribe.ru/archive/lit.book.library.ebookaccess/msg/212153

-*Информационный канал Subscribe.Ru
Адрес подписки:
Написать в лист: mailto:lit.book.library.ebookaccess-list@subscribe.ru
Отписать: mailto:lit.book.library.ebookaccess--unsub@subscribe.ru

http://subscribe.ru/ http://subscribe.ru/feedback

Доброе время суток всем!

Позвольте пару слов на тему (я постараюсь кратко :)

нет. не убедился.
Вообще забыл о чем речь - о каталоге ВСЕХ КНИГ МИРА или каталоге
для домашней библиотечки?

Вроде бы речь шла о домашних каталогах! О таких - см. ниже:

Excel.
Три (или более) столбца - Автор, название, имя_файла.
Все.
Имя файла - можно даже без указания каталога/подкаталога - если
все файлы лежат в одном месте (объем книг менее 4,7 Gb - 1 DVD-RW :)
То по имени файла он находится любым Total Commander'ом за 2-3
секунды. Им же и открывается любой формат архива, а при наличии пары
плагинов - и смотрится все, включая форматы rtf, doc, djvu, etc.

Боюсь, что ерундой занимаетесь, граждане-товарищи...

без комментариев......

или:

Юноша, тренируйтесь на кошках!

Одобрям-с! Чем проще, тем лучше!

Представил себе эту гениальную супер прогу с базой данных из 20 пунктов
- а когда я найду время туда данные забивать?....
У меня все сделано просто - дешево и сердито. А из того что вижу в
"описании" некий гибрид серверной базы данных для супер-мега-сайта и
Супер-смотрелки + FineReader в одном флаконе.... Аж страшно стало......

... Слова твои - пустые обещанья
(Г.Гёте - кажется :)

--
Дискуссионный лист "Электронная книга"
Модератор - Михаил Духонин <mihail_***@m*****.ru>
Перед вами 2566 выпуск листа, разошедшийся для 659 человек.
Постоянный адрес выпуска этого письма в архиве -
http://subscribe.ru/archive/lit.book.library.ebookaccess/msg/211429

-*Информационный канал Subscribe.Ru
Адрес подписки:
Написать в лист: mailto:lit.book.library.ebookaccess-list@subscribe.ru
Отписать: mailto:lit.book.library.ebookaccess--unsub@subscribe.ru

http://subscribe.ru/ http://subscribe.ru/feedback