Дополнительная информация в fb2 файлах

Опубликовано сб, 02/05/2009 - 01:09 пользователем lankier

Как известно, в fb2 файлы можно добавлять дополнительную информацию через тег custom-info, примено так: <custom-info info-type="ключ">значение</custom-info>

Принято решение (мною :) ) при обновлении (синхронизации) fb2 файлов создавать четыре дополнительных тега custom-info и записывать туда следующую информацию:

  1. bookid книги в либрусеке

  2. время обновления книги (создания синхронной копии)

  3. программа, которая производила обновление

  4. время поступления книги в библиотеку

Собственно вопросы.

Нет ли тут чего лишнего, или может наоборот, чего-то не хватает?

Как обозвать (на английском) эти ключи?

Комментарии

Опубликовано сб, 02/05/2009 - 03:33 пользователем nonduc

Мне кажется, что введение дополнительных внутренних тегов в «custom-info» в .fb2 будет слишком сильной модификацией стандарта с учётом того, что:
1) эта модификация будет действовать только на Либрусеке;
2) в нынешнем стандарте никаких тегов в этой секции вообще не полагается — даже «p» (сиречь параграфов, абзацев), то есть в этой секции можно разбивать текст только переводом строки.
То есть для всех остальных библиотек файлы окажутся заведомо невалидными или эту секцию будут сознательно чистить при заимствовании файлов с Либрусека. Можно, конечно, обойтись без дополнительных внутренних тегов, а просто введением четырёх обязательных строчек, каждая из которых начинается стандартно, потом двоеточие, потом конкретные данные.

Кроме того, я не совсем понял смысл четвёртого пункта — «время поступления книги в библиотеку» — это время размещения предыдущей версии книги, да? То есть дата модификации *.fb2 файла предыдущей версии, указанная в zip-архиве?

Также мне кажется, что в формулировку первого пункта нужно добавить «предыдущей версии», чтобы получилось так: «bookid предыдущей версии книги в Либрусеке». (Или здесь имеется ввиду самая первая версия — в тех случаях, когда версий уже было несколько?)

Опубликовано сб, 02/05/2009 - 03:37 пользователем lankier

Это не модификация фб2. Всё делается в соответствии со стандартом.

Опубликовано сб, 02/05/2009 - 03:46 пользователем nonduc

Подожди, подожди, с каким стандартом? Сейчас, насколько я знаю, валидатор орёт благим матом, когда в секции «custom-info» появляется хоть что-то помимо простого текста. Этот простой текст даже тегом «абзаца» форматировать нельзя. А ты предлагаешь новые теги туда засунуть…

Опубликовано сб, 02/05/2009 - 04:01 пользователем Витасик

nonduc написал:
Подожди, подожди, с каким стандартом? Сейчас, насколько я знаю, валидатор орёт благим матом, когда в секции «custom-info» появляется хоть что-то помимо простого текста. Этот простой текст даже тегом «абзаца» форматировать нельзя. А ты предлагаешь новые теги туда засунуть…

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

Я еще не пробовал работать с софтом по созданию книг, но если Вы утверждаете, что валидатор неадекватно реагирует на html-теги, верю Вам на слово...

Но, может быть, стоит рассмотреть какой-нибудь другой вариант размещения доп.информации? Раз уж нельзя поменять xml-схему... Например, придумать что-то такое:
<custom-info>
#Дополнительная информация для либрусека
file-id: 0100-abcd-ef-12345678
last-modified: 2009-05-01 17:13
</custom-info>
Написать парсер для таких строк - два раза плюнуть. Конечно, не хотелось бы так извращаться внутри XML-документа, но если это позволит избежать проблем совместимости - то почему бы и нет?

Опубликовано сб, 02/05/2009 - 04:13 пользователем nonduc

Вообще-то, если ты модифицирушь имеющийся файл, то ты должен сохранять его file-id (0100-abcd-ef-12345678) тем же. А здесь речь идёт не о file-id, а о id файла в базе данных Либрусека — это тот id, который соответствует порядковому номеру появления книги в либрусековском собрании и который следует в адресной строке вслед за b/…

Опубликовано сб, 02/05/2009 - 04:11 пользователем lankier

nonduc написал:
А ты предлагаешь новые теги туда засунуть…

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

Опубликовано сб, 02/05/2009 - 04:15 пользователем nonduc

Это было мне понятно с самого начала. И именно этому я возражаю — такой файл не пройдёт валидацию. :)

Опубликовано сб, 02/05/2009 - 04:29 пользователем lankier

Почему не пройдёт?

Опубликовано сб, 02/05/2009 - 04:33 пользователем nonduc

Я уже дважды об этом писал здесь! — потому что в этой секции согласно fb2-схеме не положено иметь ничего, кроме простого текста. То есть никакие дополнительные элементы там не положены. :)

Опубликовано сб, 02/05/2009 - 04:39 пользователем lankier

<cusom-info info-type="librusec-bookid">1234</cusom-info>
<cusom-info info-type="librusec-updater">lib.rus.ec</cusom-info>

Где здесь дополнительные теги?

Опубликовано сб, 02/05/2009 - 04:53 пользователем nonduc

Упс, да! никаких дополнительных тегов. Новые значения атрибутов! :) Заклинило меня, кажись, на фразе «четыре дополнительных тега custom-info», а первый абзац выпал из внимания. И в таком заклиненном состоянии я и писал следующие ответы! :D :D :D
Прошу больших пардонов!

Но остаются два вопроса:

Цитата:
Кроме того, я не совсем понял смысл четвёртого пункта — «время поступления книги в библиотеку» — это время размещения предыдущей версии книги, да? То есть дата модификации *.fb2 файла предыдущей версии, указанная в zip-архиве?
Цитата:
Также мне кажется, что в формулировку первого пункта нужно добавить «предыдущей версии», чтобы получилось так: «bookid предыдущей версии книги в Либрусеке». (Или здесь имеется ввиду самая первая версия — в тех случаях, когда версий уже было несколько?)

Опубликовано сб, 02/05/2009 - 04:02 пользователем set0

У меня например есть идея записывать там названия произведений входящих в сборники и собрания сочинений, и может в будушем программы библиотекари научатся ее вытаскивать, а программа создавшая файл там и так записывается.

Опубликовано сб, 02/05/2009 - 04:25 пользователем lankier

Вообще-то эта информация (список входящих в книгу произведений) есть в body. Чтобы можно было их увидеть программа просто должна уметь составлять оглавление.

Можно было бы указывать, что это сборник. Но (пока?) эта информация в база данных отсутствует.

Опубликовано сб, 02/05/2009 - 08:42 пользователем Tanja45

Простите, lankier
В том, что так сделать можно, а так же можно достать из дескрипшена прог.-биб. - верю Вам безоговорочно, т.к. до сих пор радостно попискиваю от написанного Вами валидатора для Либрусека. Но не могли бы Вы как-нибудь подоступнее объяснить цель именно такой доп.инфо в файлах?
1.Цель наличия там ID книги на Либрусеке? Для обновления локальных библиотек пользователей?
2. Время обновления книги (создания синхронной копии) - это дата правки данного файла? Его надо дублировать из history?
3. Программа, которая производила обновление - это редактор, которым велась правка? Дублировать из document-info/program-used?
Как и для чего Вы собираетесь использовать эту информацию? Если не очень лень объяснить, то постепенно дойдет и до меня.:))

Опубликовано сб, 02/05/2009 - 09:22 пользователем lankier

Наверно я не очень понятно написал в начале. Есть в либрусеке книга. У пользователей есть возможность online-редактирования метаинформацию этой книги (жанр, автор, название и т.д.) Эта информация хранится в базе данных. Если кто-то скачает fb2 файл, в его description останется та информация, которая в ней была во время добавления книги в либрусек. То, что правилось пользователями в книге отсутствует. Процедура синхронизации это прописывание непосредственно в fb2 файл всего того, что пользователи понаисправляли на странице книги. Все эти custom-info-теги будет прописывать программа, которая производила синхронизацию.

Tanja45 написал:
1.Цель наличия там ID книги на Либрусеке? Для обновления локальных библиотек пользователей?

По этому id можно будет найти книгу в библиотеке. (Можно и прямой урл писать, но id технологичней и меньше места занимает.)

Tanja45 написал:
2. Время обновления книги (создания синхронной копии) - это дата правки данного файла? Его надо дублировать из history?

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

Tanja45 написал:
3. Программа, которая производила обновление - это редактор, которым велась правка?

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

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

Опубликовано сб, 02/05/2009 - 09:31 пользователем lankier

Собственно вот мои предложения по названиям ключей:
librusec-book-id
librusec-added-at
librusec-updated-at
librusec-updater

Опубликовано сб, 02/05/2009 - 10:21 пользователем Tanja45

Спасибо за разъяснения. От меня изначально ускользнуло наличие (или скорое появление) программы-синхронизатора, способной вносить информацию из базы данных Либрусека непосредственно в файл книги. Правильно ли я поняла, что названия ключей:
librusec-added-at - 4.
librusec-updated-at - 2.
librusec-updater - 3.
Действительно ли нужен ключ 3.?

Опубликовано сб, 02/05/2009 - 10:56 пользователем lankier

Tanja45 написал:
От меня изначально ускользнуло наличие (или скорое появление) программы-синхронизатора, способной вносить информацию из базы данных Либрусека непосредственно в файл книги.

В принципе она уже написана (обе версии - online и offline), правда осталось ещё несколько вопросов (типа названия ключей). Ещё не очень понятно что делать с кешированием обновленных файлов (не обновлять же файл при каждом скачивании, большая нагрузка на сервер будет).

Tanja45 написал:
Правильно ли я поняла, что названия ключей

Угу. Я решил поменять последовательность ключей. Вообще-то это не важно, но мне так больше нравится. :)

Tanja45 написал:
Действительно ли нужен ключ 3.?

Это аналог program-used из document-info. Можно было бы записывать эту информацию непосредственно в program-used, но не хочется - усложнится и замедлится работа апдейтилки-синхронизаторки. А нужен, чтобы знать того, кто приложил руку к файлу (в случае возникновения каких-нибудь ошибок).

Опубликовано сб, 02/05/2009 - 11:17 пользователем Tanja45

lankier написал:
Ещё не очень понятно что делать с кешированием обновленных файлов (не обновлять же файл при каждом скачивании, большая нагрузка на сервер будет).
Т.е. синхронизация будет происходить не в файл, лежащий на сервере, а в файл, закачиваемый пользователем в момент закачки? Если бы в файл на сервере - то можно обновлять раз в сутки. Но тогда необходимо предусмотреть систему отката, на случай массового вандализма. Прецеденты были.
lankier написал:
Это аналог program-used из document-info. Можно было бы записывать эту информацию непосредственно в program-used, но не хочется - усложнится и замедлится работа апдейтилки-синхронизаторки. А нужен, чтобы знать того, кто приложил руку к файлу (в случае возникновения каких-нибудь ошибок).
Про аналог я так и поняла. Так ведь
пока таких программ предполагается ровно 1 штука, нет? Как узнать, кто приложил руку? Просто увидеть с сервера или локального компа?

Опубликовано сб, 02/05/2009 - 12:33 пользователем lankier

Tanja45 написал:
Т.е. синхронизация будет происходить не в файл, лежащий на сервере, а в файл, закачиваемый пользователем в момент закачки?

Тут что-то я не очень понял.
Примерно, как мне кажется это должно работать:
На сервере лежит оригинальный файл, кем-то добавленный в библиотеку; скажем 1234-orig.fb2.
Дальше кто-то хочет скачать этот файл. Берется 1234-orig.fb2, синхронизируется и выдается пользователю.
Вот тут возникает вопрос кеширования. После того, как пользователь скачал файл, движок сохраняет синхронизированную версию в 1234.fb2 и если кто-то опять захочет скачать его, то выдается этот синхронизированный файл.

Есть другой вариант. Добавить в таблицу книг в базе данных доп. поле (скажем Edited).
При редактировании метаинформации в него записывается 1. Раз в день (или когда кто-нибудь скачивает файл) происходит синхронизация файлов у которых Edited равно 1.

Ну и третий вариант - нафиг кеширование. Синхронизировать в момент скачивания файла. Но это надо смотреть на нагрузку сервера. Можно для начала именно так попробовать-потестировать, и если нагрузка не очень возрастет, то и нечего огород городить.

Tanja45 написал:
Но тогда необходимо предусмотреть систему отката, на случай массового вандализма.

Оригинальный файл и так должен быть сохранен. Предполагается, что синхр-ка с оригинальными файлами и будет работать.

Tanja45 написал:
Так ведь пока таких программ предполагается ровно 1 штука, нет?

Сейчас подсчитаю... Одна-две-три... У меня их ровно одна целая и пять десятых штуки. Есть оффлайновая утилита в составе fb2utils и некий код на php, который сейчас работает из командной строки и апдейтит указанный файл. Но этот код еще надо прикрутить к движку.

Опубликовано сб, 02/05/2009 - 12:49 пользователем Tanja45

lankier написал:

Оригинальный файл и так должен быть сохранен. Предполагается, что синхр-ка с оригинальными файлами и будет работать.
Ага, спасибо, ясно.
lankier написал:
Сейчас подсчитаю... Одна-две-три... У меня их ровно одна целая и пять десятых штуки.
Да, это ровно:)).

Опубликовано сб, 02/05/2009 - 15:49 пользователем larin

lankier написал:

На сервере лежит оригинальный файл, кем-то добавленный в библиотеку; скажем 1234-orig.fb2.
Дальше кто-то хочет скачать этот файл. Берется 1234-orig.fb2, синхронизируется и выдается пользователю.
Вот тут возникает вопрос кеширования. После того, как пользователь скачал файл, движок сохраняет синхронизированную версию в 1234.fb2 и если кто-то опять захочет скачать его, то выдается этот синхронизированный файл.

C кешированием всё понятно и давно сделано для прочих форматов (txt, rtf, epup...)
Файл генерируется в момент обращения пользователя, пакуется зипом и сохраняется на случай подобных запросов.
Единственно, при любом изменении информации о книги закешированный файл надо удалять, но это как-раз просто, все изменения проходят через одно место.

Опубликовано сб, 02/05/2009 - 16:30 пользователем lankier

Ага. Тогда я никаких проблем больше не вижу.
Поскольку возражений по поводу названий ключей не было, оставил какие сам придумал.

Прикрепил к посту апдейтилку на php. Работает из командной строки, два аргумента: имя файла и bookid. Запросы к базе данных сделаны через стандартные функции mysql_* (не через движковые). Результат выводится в stdin. Работает ессно только с валидным xml. Вроде ничего не забыл.

Опубликовано вс, 03/05/2009 - 04:17 пользователем lankier

Сделал небольшие изменения в апдейтилке. Основное - избавился от функции libXmlIconv и глобальной переменной для неё. См. прикрепленный файл.

Опубликовано вс, 03/05/2009 - 00:37 пользователем nonduc

Кажется, в базе данных появился новый блок, который просто просится на место рядом с четырьмя имеющимися: именно блок с дополнительной информацией, помещаемой в квадратных скобках после названия.
Предлагаю название ключа — librusec-add-title-info.

Опубликовано вс, 03/05/2009 - 02:21 пользователем Рыжий Тигра

ЗдОрово! Наконец появляется способ отличить в локальной библиотеке либрусековскую книгу от не-либрусековской. :) Особенно приятен librusec-book-id.
Кстати, а может, заодно всё-таки сделать автомат уведомления пользователей, выложивших или скачавших книгу, о её изменении? А то неудобно вручную отслеживать несколько сотен книг - не обновилось ли случайно что-нибудь.
X