Други, а есть ли среди нас программеры умелые ?
Опубликовано ср, 14/05/2008 - 10:37 пользователем Kuguar
Други, а есть ли среди нас программеры умелые ? Может собраться и написать распределенную систему в стиле осла (dunkey, emule), но Для тех, кто не в теме, могу сказать что штука особенна удобна тем, что невозможно
|
|
Комментарии
Re: Други, а есть ли среди нас программеры умелые ?
Фигня...
Это тот же анонимус-прикси, только динамический и запутанный.
Т.е. того кто ходит, отследить действительно трудно. А вот КУДА ходят отследить как нефиг делать. Ну как можно куда то пойти, не имея адреса\ссылки\ключа. А если оно есть у кого либо, то и найдется и у всех кому надо.
Лишие сложности организации и кросс доступа. Оно надо ?
Re: Други, а есть ли среди нас программеры умелые ?
ох и нравится мне твоя категоричность:) Дочитай сначала до конца, а потом делай такие заявления:) Мы ж не спешим.
Смотреть надо на скрытый сервис. Там все запутано точно так же как и для запрашивающей стороны.
Резюме - мне это тоже не очень нравится, но, лучшего анонимизатора для ОБЕИХ сторон коннекта, я не знаю.
ну тогда писать с нуля, но по-моему, это еще сложнее. Хотя смотря для кого, вобчем здесь спец.-программер должен слово сказать.
Re: Други, а есть ли среди нас программеры умелые ?
Тут все просто.
Если я изначально куда либо иду, то я должен знать адрес или ссылку или еще какой либо идентификатор желаемого. Причем совершенно не важно, как сложно я туда попадаю.
Если туда попадаю я, то и может попасть и злодей, точно так же набрав такую же ссылку.
Достаточно иметь несколько узлов этой сети, принадлежащим злодеям, что бы путем простого статистического анализа найти все серверы с лежащим файлом.
Соответственно если серверы большие и выделенные, тогда все проблемы остаются теми же, что и были. Если же серверов множество и они мелкие, тогда это ничем не отличается от прямого обмена шифрованными файлами.
Ну не вижу я тут плюсов никаких :(
А запутанность, это признак слабости алгоритма и потенциальной возможности для дырок.
Все по настоящему надежные криптосистемы просты.
Так чем же FreeNet плох ?
Вот как будет свободный момент, я за день-два могу расшарить всю библиотеку. Т.е. полноценный файловый доступ всем желающим, хоть завтра. Вопрос в структуризации только.
Вот тогда и потестируем на поиск-доступность.
Кста, надо будет туда базу либрусека отмиррорить, если Ларин добро даст.
Re: Други, а есть ли среди нас программеры умелые ?
а как это, если лежащие файлы, и их имена тоже, при передаче шифруются средствами Васты?
Ладно, в любом случае вариант ТОР+Васта - это для параноиков. А ломать ТОР, чтоб бороться с обменом книгами - это паранойа в квадрате.
я уже несколько раз писал. Для обмена - почему бы и нет. Хотя мне не нравится идея отдавать часть своего диска под непонятно что. Но ладно. А вот рассматривать ее как систему распределенного хранения данных - а именно так она и позиционируется - нельзя. Не доросла еще потому что.
Ну и удастся ли к ней прикрутить свои собственные приблуды, чтоб автоматом с базой работало, не знаю, не смотрел.
Re: Други, а есть ли среди нас программеры умелые ?
Re: Други, а есть ли среди нас программеры умелые ?
А как вам такая структура ?
Каждый желающий открывает в FreeNet страницу содержащую
1. локальную базу данных пользователя.
2. файловый массив данного пользователя
3. массив ссылок на аналогичные страницы других пользователей
В локальной базе данных содержутся записи о файлах, т.е.
автор-название-проч. и ссылка на файл в своем или чужом
файловом массиве.
В файловом массиве лежат файлы, которые желает хранить-сопровождать
данный пользователь. Полное удаление какого либо файла происходит
только тогда, когда этот файл удаляют все пользователи хранящие у
себя его копии. Кста, по количеству копий можно судить о востребованности
конкретного файла.
Локальные базы данных могут иметь различную программную реализацию.
Достаточно того, что бы они имели унифицированный интерфейс запросов.
В такой системе поиск выглядит так - искомое ищется в локальной базе
данных, затем передается по списку ссылок на соседние узлы, далее
на соседние этих узлов и так, до достижения критерия окончания.
В результате формируется список записей с указателями на файлы.
Его можно отсортировать, отфильтровать и выбрать нужный файл(ы).
Т.е. вся работа сводится в создании программы, организующей интерфейс
между базами данных и локальным-удаленным поисковиком.
Re: Други, а есть ли среди нас программеры умелые ?
Re: Други, а есть ли среди нас программеры умелые ?
Чем глобальная база в этом случае поможет ?
Вообще, я ка то слабо улавливаю отличие понятия "база данных", от ссылочных списков с механизмом поиска.
Т.е. иначе говоря, что такое умеет MySQL или Oracle, что нельзя организовать с помощью файловой системы и bash скриптов, но много медленней, естественно.
Безусловно. Вот ценители и будут их хранить.
Оценочно, по моим экспериментам с FreeNet, поиск будет происходить в пределах нескольких минут. Не более 10, типично 3..5.
Скачивание, в зависимости от востребованности книги от минут-секунд, для востребованных, до 1..2 часов для редких единичных копий.
Для начала нужно написать-подобрать кандидата на локальную базу ссылок. Т.е. что то типа библиотеки с возможностью обращения от других программ.
Re: Други, а есть ли среди нас программеры умелые ?
Если база - это одна таблица, тогда безусловно ничего. Но база - это сложная структура, где можно описать книгу намного более подробно. Например в списках тяжело задать разное число авторов для разных книжек - надо вводить ограничения сколько может быть максимум. Вон в бук-либе - два и все. А насчет классификации я вообще молчу - в списках задать для одной книги классификацию сразу по нескольким системам вообще невозможно. А именно это и интересно для поиска. По этому поводу в ФРБР написано много - Стажер ссылки давал. Я считаю, что там для книг слишком много лишнего, потому попытался в своей структуре упростить. Вот сейчас занимаюсь тем, что к базе бук-либа добавляю книжки в фб2 для тех, что в бук-либе есть в тексте. При этом у меня для одной книги автоматом появляется еще одна классификация - в фб2.
а если без базы, то ничего городить и не стоит, потому как сейчас полно систем, ориентированных на обмен именно что файлами. Те же торренты или осел. Городить еще одного нет смысла.
Re: Други, а есть ли среди нас программеры умелые ?
Одна таблица, это один каталог.
Но файловая система более сложная структура. :))
Во первых она древовидная, во вторых может быть перекрестно-ссылочной, путем ярлыков или линьков.
Т.е. я так думаю, что базу данных любой структуры можно реализоватья в виде файловой системы. Естественно с потерей компактности и скорости.
Но все это не так существенно, т.к. предлагается хранить книги как файлы, а библиографию и ссылки хранить в распределенной глобальной базе данных.
grep не поможет, однако ?
Ну почему же без базы. Глобальная база, которая строится из множества локальных.
Вполне возможно, что локальные базы имеют разные структуры. Тогда при запросах содержащие соответсвующие параметры, они должны игнорироваться.
Т.е., к примеру, вы ищите книгу по автору-названию-издательству .
При поиске в локальных базах данных, если они имеют поле "издательство", то фильтрация производится. Если не имеют, то нет.
Так как вы строите запрос, то и вариант обработки отсутствующего параметра может выбрать нужный вам.
Именно так.
Локальный юзер хранит у себя в открытом виде любое желаемое число книг. Те, которые он считает нужным расшарить, получают имя-ссылку на соответствующей WEB странице в FreeNet.
Можно напрямую скачивать ее оттуда по этой ссылке.
Но это неудобно, т.к. надо сначала найти искомое. Для поиска, у каждого локального пользователя есть локальная база данных удобной ему структуры. В ней, кроме библиографии, содержится ссылки на те самые файлы в FreeNet. Причем неважно, расшаренные у этого пользователя или у другого.
Для того, что бы объединить все локальные базы данных в глобальную нужны следующие две вещи.
1. База данных должна уметь поддерживать внешние запросы (из Free NET).
2. База должна содержать массив ссылок на другие локальные базы (в Free NET).
Теперь достаточно иметь сервис, который преобразует внешний запрос в запрос к локальной базе и локальный запрос к базам данных из списка.
Таблица, содержащая ссылки на интерфейсы к базам данных других пользователей. К примеру, в случае открытой сети - IP адреса и порты.
Библиотека, это база данных библиографии и ссылок на тексты с каким либо пользовательским интерфейсом.
Если есть возможность обращаться к этой базе данных от других программ, через сокеты или pipы, то это она и есть.
Т.е. если библиотека строится на базе данных с известным интерфейсом (MySQL, sqlite). То она вполне годится для построения глобальной базы банных.
Re: Други, а есть ли среди нас программеры умелые ?
Дано
1.на локальном компе есть две файловые структуры - одна - бук-либ, вторая - большая свалка файлов в фб2.
2.есть база для буклиба. Есть список для фб2-файлов с дескрипторами фб2 - фактически описание книг в файлах.
3.в бук-либе и в файлах фб2 есть свои системы классификации, одна - трехуровневая, вторая - плоская с неявным первым уровнем (в списках есть только второй уровень)
Надо
по классификации из бук-либа найти все файлы в фб2, если они есть для соответсвующих текстовых файлов и наоборот.
Расскажи куда здесь grep совать.
сорри, все что дальше - запутался окончательно, каждое второе слово рождает новый вопрос, может имеет смысл перенести в личку? Или у меня gtalk есть, чтоб по быстрому выяснить одно мы хотим или нет?
Re: Други, а есть ли среди нас программеры умелые ?
Есть какой то минимум унифицированных полей.
Т.е. как минимум Автор1...АвторN, Название, Язык оригнала.
Лучше всего воспользоваться уже существующими именами полей или взять
какой либо удобный существующий формат.
Этот, общий для всех пользователей формат полей используется для запросов.
Т.е для неких SQL подобных запросов единой формы.
Так как локальные базы могут иметь другие имена полей или сложно-ссылочную структуру или
вообще не иметь каких либо полей, то для каждой отдельной базы данных (пользовательской библиотеки) нужен некий интерфейс, который переводит из глобальной формы в локальную.
Это решает вопрос не совместимости локальных баз данных, т.к. для каждой неизвестной
базы данных достаточно будет задать логику соответствия полей.
Скорее всего, этот интерфейсный модуль будет везде одинаковым, а настройка на локальную базу данных будет задаваться в его конфигурационных файлах.
Re: Други, а есть ли среди нас программеры умелые ?
дык я и предлагаю воспользоваться полями из моей базы. Других предложений кроме твоих неясных высказываний типа "существующими именами полей" или "удобный существующий формат", я не вижу. Конкретно, плиз - какие имена существуют и где, какой формат удобный и т.д.
свят, свят. еще и язык свой разрабатывать - кто это будет делать? Ну в смысле - весь инструментарий для этого нового языка? Почему не использовать стандартный SQL?
Сорри за нескромный вопрос - ты пробовал задавать такую логику для структур, немного сложнее нежели линейные списки? Да и вообще - зачем эти сложности? Не проще ли обязать всех, кто хочет быть в системе, иметь базу одной структуры?
Ну и на главный вопрос ты не ответил. Как будут синхронизироваться сами данные в локальных базах. Ну, типа, если я даю запрос найти какую-то книгу а мне в ответ выдает 100 ссылок из разных баз с именами файлов, что отвечают этому запросу, то как я узнаю, это одна книга в 100 экземплярах, 10 разных вариантов по 10 экземпляров или еще как? Ну и с очепятками или различным написанием фамилий авторов как быть. С классификациями в разных системах - снова таки, как быть.
Re: Други, а есть ли среди нас программеры умелые ?
А я вроде как и не протестовал. Даже наоборот, весьма рад, что есть желающий сделать глобальный формат запроса.
А туманность тут именно от того, что не особо то и важно, какие именно. Лишь бы максимально полные были.
Я так предполагаю, что это будет подмножеством SQL, так как будем брать только необходимое, а не все что там имеется.
Если можно не напрягать узеров, то лучше их не напрягать. Да и локальные базы могут быть заточенны под что то конкретное, типа - база юридической информации, с годами, параграфами, ссылками, но без авторов или база худ-литературы.
Если файл конфигурации будет прост и понятен, то подключение любой более-менее упорядоченной базы будет весьма прост.
Я предполагаю, что особенно в начале, подавляющую массу будут составлять небольшие частные библиотеки без явной базы данных со структуризацией по файловой системе.
Т.е. как тут уже упоминалось - каталоги по имени авторов, в которых лежат файлы с названиями произведений.
Различать их можно только по тому что занесено в конкретные базы данных и по ссылкам.
Т.е. одинаковые описания могут подходить для разных файлов и наоборот. Одинаковые ссылки могут иметь различное описание в базе.
При поиске будут задаваться критерии, т.е. если есть разных 100 описаний на разных 100 ссылок одного и того же произведения, то это означает что они действительно различаются. Может кто то правил ошибки в тектсе, кто то форматировал, кто то добавил картинок.
Выбор, что качать, за пользователем.
Держателям локальных библиотек потребуется некая утилита, которая будет производить чистку-сверку локальной базы. Т.е. искать и объединять дупы по ссылкам и по описаниям, искать и удалять не действующие ссылки. Возможно даже сверять тексты и править орфографию. Но все это по желанию и под управлением хозяина локальной библиотеки.
Для предотвращения спама и замусоривания, нужна возможность задания списка локальных баз, которые игнорируются при поиске. Тогда после некоторого времени пользования все мусорное и неупорядоченное постепенно отсеется.
Re: Други, а есть ли среди нас программеры умелые ?
дык вот я и спрашиваю насчет этого файла конфигурации. Вот у меня есть задача заливать в свою базу разные списки - ну, типа, бук-либ, фб2, потом хочу научку типа колхода, и то получается не просто. А ты - между базами разной структуры! Научи как это делать, я этого не умею. На примере.
это уже есть сейчас - я свои коллекции, с которыми вожусь, набрал на торрентах как раз в таком виде. Баз просто нету. Если ты знаешь где есть - покажи.
т.е. координации содержимого в отдельных локальных базах нет? Я правильно понял? Ну и чем это отличается от того, что есть сечас? Ну, в смысле, и сейчас книжные маньяки собирают завалы кто как захотел, каждый ваяет сам себе какие-то утилиты для чисток/отлова и т.д. Есть несколько библиотекарей, которые облегчают жисть для завалов фб2. Ну и все.
Но как сделать так, чтобы появилась какая-то координация, я не понял. НУ в смысле, какой план действий? Типа делай раз - получишь одно, делай два - получишь еще чего-то, делай три - еще что-то.
Re: Други, а есть ли среди нас программеры умелые ?
Господа! Вы эта, ну совсем уж бред-то не несите? Прежде чем обсуждать проблему, а тем более - что-то делать, было бы нефигово если не освоить опыт предыдущих поколений, то хотя бы войти в курс.
"Распределённая" база данных с унифицированной схемой, отражающаяся на реальную базу данных с любой схемой - это протокол Z39.50. Ему лет, я подозреваю, больше, чем участникам столь бурной дискуссии. Схема данных для библиографической информации называется bib1. Там и ещё есть схемы...
Фигня эта более-менее успешно работает и ныне, и работала бы ещё успешней, если бы простые пацаны, которым читать спецификации западло, не понаписали бы горбатых реализаций этого протокола. Причём чем ближе к нашему времени пацан - тем горбатей реализация....
Другие ваши гениальные задумки - они тоже... имеют историю. И всё это, заметьте, плохо кончилось. Библиотечных программ с хранением файлов, без хранения файлов, распределённых, централизованных - написана фигова туча. Как мальчиками-энтузиастами, так и специально заточенными программистами Библиотеки конгресса. И массой коммерческих контор различной степени крутизны. И среди этих программ нет ни одной не то, чтобы хорошей - а сколь-нибудь отвечающей реальным потребностям простого читателя.
Резюме:
Я сказал - frbr-like централизованная база данных для библиографической информации + распределённая файловая система - значит, так и побежим. Или не побежим. Но иначе - не побежим точно.
Re: Други, а есть ли среди нас программеры умелые ?
Ну и как возможно?;) Что делать?;) Что конкретно вы предлагаете.
Re: Други, а есть ли среди нас программеры умелые ?
Ну, дело в том, что "как" - изложено в виде статьи, с которой я, типа, собираюсь выступать на, типа, конференции.... Поэтому по персональному запросу я могу её прислать, а вот публиковать - пока не готов...
Но идея, в общем, проста. Поскольку frbr говорит о неопределённом количестве типов сущностей, имеющих неопределённое количество неизвестных наперёд атрибутов - то альтернативы инвертированной схеме базы данных как бы и нет. А раз так - то вот:
Отношение "Типы сущностей":
ID_типа_сущности
Комментарии
Отношение "Сущности":
ID_Сущности
ID_типа_сущности
Отношение "Типы атрибутов сущностей"
ID_типа_атрибута
Helper
Комментарии
Отношение "Атрибуты сущностей":
ID_Сущности
ID_атрибута
ID_типа_атрибута
Значение атрибута
Дальше помним, что сущности могут быть объединены связями. При этом знаем ;-) что связи бывают двух типов - между сущностями как таковыми, когда не важна их внутренняя структура, и между атрибутом сущности и всем остальным. Связи первого типа обычно бывают замысловаты и образуют графы, которые хочется поименовать, а второго - просты и соединяют лишь два объекта, выражая то обстоятельство, что один из них является как бы свойством второго.
В этом свете:
Отношение "Структуры":
ID_структуры
Комментарии
Отношение "Структура":
ID_структуры
Предок-ID_сущности
Потомок-ID_сущности
;а отношение "Атрибуты сущностей" нужно дополнить следующим образом:
Отношение "Атрибуты сущностей":
ID_Сущности
ID_атрибута
ID_типа_атрибута
Значение атрибута
ID_связанно_структуры
ID_связанной_Сущности
ID_связанного_атрибута
Всё. Остаётся добавить к основе навороты для практического удобства (которые я тут опускаю) - и с помощью этой схемы можно выразить Универсум! :-)
Но схема - это только пол-дела. Треть, точнее ;-)
Дальше я предлагаю в одну централизованную базу данных по этой схеме залить все имеющиеся в наличии в электрическом виде библиографические записи на русскоязычную литературу.
А все имеющиеся в наличии русскоязычные электронные тексты - в распределённую файловую систему.
И связать одно с другим через, допустим, ID_Сущности - что полностью делает централизованную базу библиграфической информации не связанной с распределённым файловым хранилищем. Или через атрибут сущности - имя файла, что, конечно, обнаруживает связь, но зато позволяет иметь содержательные имена файлов. Но ничто не мешает включать в имя файла ID_Сущности ;-)
Поскольку очевидно, что "Большая Централизованная База Данных Со Всеми Сведениями Об Авторах, Произведениях, Переводчиках И Фанфиках" - это лишь развитие массово ныне существующих электронных каталогов библиотек, то на эту часть проекта можно вообще забить, и сосредоточиться на распределённом хранении. А в имя файла включать содержимое поля 035 MARC-записи на интересующую книгу в каталоге, например, Ленинки. В случае OFFSystem это гарантирует вам получение требуемого в два клика. Если оно, конечно, будет в хранилище.
Re: Други, а есть ли среди нас программеры умелые ?
ну да, ну да. Универсум это, конечно, хорошо. Ну а я тогда продолжу ковырять свою базу - мне универсум не нужен.
ага, понятно. Ну дык в чем проблема - бери на торрентах свалки файлов, переименовывай их на основе поля 035 MARC-записи в каталоге Ленинки - и размещай в OFFSystem. Успехов. Когда приходить смотреть на результат?
Re: Други, а есть ли среди нас программеры умелые ?
Т.е. вы считаете, что обсуждение не является процесом "вхождения в курс" и предлагаете заняться этим каждому в одиночестве ?
Ну, мы же не знаем сколько вам лет, так что оценить не можем. :))
Можете ссылкой поделиться или аннотацией или вы намерены только эрудицией блеснуть ?
Ссылки можно, где работает и как мы этим можем воспользоваться ?
Мы услышали! :))
Но к сожалению еще не увидели...
Мож вы как то упустили - ну а как там с анонимностью клиентов и защищенностью контента ?
В общем то это и есть главное, т.к. без оного нам и либрусека вполне хватает.
Re: Други, а есть ли среди нас программеры умелые ?
слышал, даже пытался как-то поковырять. Да не умелый я программер, в обчем. Вывод - для моих целей использовать нельзя, потому как слишком накладно с точки зрения разработки - надо к базе интерфейс лепить чтоб подключить этот протокол, а там - мама не горюй с форматами. Ну и, кроме того, в тех реализациях что я видел, обмен идет по заданному порту с реального адреса ну и как закрывать все это - непонятно. Это имеет смысл приспособить чтоб вытащить недостающую библиографию по имеющему списку книг. Вот если бы здесь ты помог - было бы хорошо.
Я уже просил показать хотя бы структуру "frbr-like базы данных". И где?
Про инструменты работы с ней я вообще молчу. А при голой базе мне, в принципе, по барабану в какой именно структуре скрещивать бук-либ со свалкой фб2. Пока меня устраивает моя база, она кое-какие идеи ФРБР содержит, мне этого достаточно. Я ж не претендую на "библиотеку конгресса":)
Re: Други, а есть ли среди нас программеры умелые ?
ну как, ребят, удалось что-нибудь накодить?)
Re: Други, а есть ли среди нас программеры умелые ?
Если есть желание помочь, то есть несколько задач по сравнению содержимого базы. База на мускуле. Кодить можно на перле. например.
Re: Други, а есть ли среди нас программеры умелые ?
1. желание есть, но вот только умение кодить на перле только самое поверхностное, к сожалению...
2. интересно, что такое мускул. объяснишь?
3. правильно ли я понимаю, что будет введена поддержка замены устаревшей версии и скачивания наиболее новой? а то так будет путаница в версиях =(
Re: Други, а есть ли среди нас программеры умелые ?
перл не обязательно, вполне можно и чего-то другое. Главное, чтобы с базой работало ну и не требовало на локальной машине чего-то большого запускать,например апача. Т.е. было отдельным приложением.
А что ты умеешь/знаешь? Потому как кроме базы, есть еще задача обмена файлами. Здесь или свое писать или присоседиваться к имеющемуся. Даже в этом случае надо разрабатывать какие-то средства встраивания в имеющиеся системы в виде или плагинов или отдельных специализированных модулей. Т.к. в этом направлении я определился только на уровне требований, то использовать можно чего угодно, что подходит по требованиям и возможностям для разработки.
MySQL
если имеется в виду книга, то да. Новая будет менять старую в базе. А в файловых архивах будет меняться автоматом по мере расползания по сети.
Страницы