Пиринг чем не новый вариант сетевой библиотеки?

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

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

Это на низком уровне, ну и завернуть конечно в красивую оболочку типа библиотекаря. Или просто к нему подстыковать, для простоты.

Ценность идеи - именно в распространенной "библиографии", возможности искать по частичной информации о книге (вообще говоря, даже по цитате текста Smile

) и в автоматической поддержке общего архива. То есть не каталог новинок.

Смотрите, какя крутизна могла бы быть: как только с какого то узла в сеть попадает новая книга, узля начинают ее ассимилировать - создают резервные копии, обновляют библиографии и т.д. В идеале должно получиться так: вероятность того, что хоть раз попавшая в сеть книга, исчезнет, весьма мала при потере до 30% узлов. Этого нет в упомянутых ранее сетях.

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

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

Есть сетевой запрос - книги, которые хочется получить в личную библиотеку. В зависимости от запроса, хоть одну книгу, хоть всю библиотеку. Торрент тут опять не нужен, так как в качестве элемента докачки вполне сойдет отдельная книга - либо получил, либо нет. Рвать ее на части, еще раз скажу, скучное извращение Smile

Как только сеть построится и начнет работать, желающих скачать всю библиотеку станет мало - будут скачивать серии, авторов и т.д., но не всю же библиотеку Smile

И тут торенты не нужны.

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

А вот чего сразу надо - некий сервер библиографии, чтобы упорядочивал title-info - хотя бы author.id, а то как то непонятно, каким образом его назначать. Никто случаем не решал такую задачу?

На покет в принципе спортить тоже можно будет. А так - сразу будет *nix, win*, mac.

Да понятна идея, и я в общем то о том же. Правда идеями сыт не будешь, нужна реализация Smile

Единственно что вызывает некоторые сумненья - будет ли оно работать без модерации...
Не тот у нас народ, в большинстве, все таки. Без модераторов будет полный бардак.

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

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

Кстати, стоит и рецензии читателей тоже держать в распределенном архиве, и оценки.

А дальше как угодно - хочешь ищешь утвержденные, хочешь любые. В общем надо еще подумать.

Добавлено спустя 56 минут 2 секунды:

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

Так wx ведь не на питоне, его то уж наверно все равно отдельно ставить? Wink

Ничего ваще не надо будет ставить - будет один огромный экзешник, а в него будет запихуем и питон, и wx, и все такое, типа pywin32 и lxml. Таким образом питон в кучу разных программ встроен - даже и не видно, что он там есть. В некоторые игры даже - кажется, в одну из последних цивилизаций. Или что то вроде. Правда, не уверен, что такое счастье есть для мака... тем более для *никса. Но на последнем питон почти всегда стоит сам по себе Smile

Естессно, если поставить сперва питон, а потом wx, то можно запаковать в .exe только собственно скрипты, ну и мелкие пакеты, типа lxml. Вот в чем счастье Smile

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

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

easy_install scribe

На мой взгляд - начинать нужно с самого обычного торрент-трекера. Каталог книг, поиск - на сайте трекера. Книги релизятся стандартным для битторрента способом, описания на сайте можно создавать автоматом из инфы в fb2 (робот на сайте может закачивать анонсированные книги, парсить и писать в БД инфу).
Да, получается не слишком удобно, и полностью не устраняются проблемы с законом (хотя трекер и не хранилише файлов, но всё равно...). Зато это несложно сделать (свободных трекер-движков навалом) и легко использовать прямо сейчас, с существующими torrent-клиентами.

А следующим шагом - взять какой-нить торрент-клиент и надстроить его недостающим функционалом. Или написать отдельную прогу. Не принципиально.

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

Проблема со скачиванием книг по одной тоже имеет решение. Например uTorrent умеет скачивать по ссылкам из RSS. Таким образом, желающие смогут автоматически качать и раздавать новые книги.
Но всё это можно будет улучшать в своём клиенте, когда/если будет видно что проект выживет и станет ясно что, на самом деле, нужно улучшать.

Ещё было замечание, что с торентом будет излишний трафик т.к. файлы маленькие. Возможно. Но не думаю, что это проблема - именно из-за того, что файлы маленькие. Smile

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

Если есть желающие поспособствовать, лучше давайте по делу подумаем. Вопрос первый:

Сделал я базку по схеме FB2.0/description, со всеми ее наворотами. Получилось не круто: очень навороченно, не удобно работать, медленный импорт, огромная база (из за множества индексов, в том числе). На моей тачке 8 книг/с.

Сделал сильно упрощенную базу - получилось гораздо лучше, примерно 25 книг/с. Есть предложение обсудить, какой минимум полей из description реально нужен для ежедневного пользования, быстрого поиска и т.д. А остальные поля по необходимости будем вытаскивать из собственно документа и не перегружать базу. Сейчас используется следующий набор, плз высказывайтесь:

class Weblink(DataObject):
url = Col(key='uniqie')

class Email(DataObject):
email = Col(key='uniqie')

class Person(DataObject):
first = Col(key=1)
middle = Col(key=1)
last = Col(key=1)
authorid = Col(key=1)
nick = Col(key=1)
page = MultiJoin('Weblink')
email = MultiJoin('Email')

class Genre(DataObject):
genre = ForeignKey('Genres')
match = IntCol(default=100)
book = ForeignKey('book')

class Keywords(DataObject):
word = Col(key='uniqie')

class Genres(DataObject):
__metaclass__ = smartClass
gid = Col(key='uniqie')
text = Col()
genre = Join('Genre')

class Sequences(DataObject):
name = Col(key=1)

class Sequence(DataObject):
sequence = ForeignKey('Sequences')
number = IntCol()
book = ForeignKey('Book')

class Shelf(DataObject):
name = Col()
guid = Col(key=1)
path = Col()
notes = ForeignKey('Notes')

class Notes(DataObject):
text = Col()

class Dupe(DataObject):
book1 = ForeignKey('Book')
book2 = ForeignKey('Book')

class Book(DataObject):
author = MultiJoin('Person')
translator = MultiJoin('Person')
docauthor = MultiJoin('Person')
title = Col(key=1)
srctitle = Col(key=1)
annotation = Col()
docid = Col(key=1)
sequence = Join('Sequence')
genre = Join('Genre')
texthash = Col()
path = Col()
date = Col()
lang = Col()
srclang = Col()
arcname = Col()
shelf = ForeignKey('Shelf')
keywords = MultiJoin('Keywords')

По мне так вообще достаточно примерно такого:

Mike Sinkovsky угу, вполне достаточно.

Mike Sinkovsky Alan
Не достаточно. Сейчас наполняю свою библиотеку и сталкиваюсь с различными ситуациями. Например:
1.Две книги из различных источников. Одинаковая версия, к примеру 1.1. В первой книге авторы документа Aut1,Aut2 а у второй - Aut1, Aut3. Если принять Вашу схему, то это одна книга.
2.Одна зарубежная книга - разные переводчики. => два разных документа.

Следовательно:

Cd_spb в приведенных тобой примерах - да, это одна книга и две книги. Вполне устраивает. имхо, конечно, но ведь именно про имхо и спрашивали?

Про ид забыл - тогда вообще проблемы нету и точно всего хватает...