К сожалению, подобный поход не работает на ZX Specrum в практическом плане, потому что оказывается слишком медленным. Тут парадигма программирования (приводящая к успеху) несколько иная. Могу рассказать, если есть интерес.
Раз статьи (как я предлагал) не последовало, то хотелось бы всё-таки услышать хоть в виде комментария. Вопрос интересный.
Я рекомендую еще раз всё прочитать. Пользователь, который хочет получать обновления базы, пишет приложение, которое будет посылать HTTP запросы в JSON API, в котором доступна для чтения вся информация, касающаяся общей информации (без комментариев, голосований итд).
Таким образом, внутренняя структура базы не играет особой роли, играет роль структура JSON-ответа.
Вести отдельную базу для каждого источника — это непрактично, но индексный список уже есть. Новые данные уже приближаются к структуре базы, именно для этого внутренние парсеры и нужны.
Отдельный скрипт-интегратор уже проверяет информацию на дупы и уже пытается найти и подвязать информацию из имеющегося набора.
Стопроцентной полноты в реальном мире не существует, есть минимальный набор, без которого нет смысла что-то импортировать. Это уже делается, именно об этом и есть статья.
Сигнал админу — это непрактично, никто на зарплате не работает, чтобы информация месяцами дожидалась, когда у админа дойдут руки. Поэтому импортируем что есть, а потом разруливаем проблемы.
Мне тоже непонятно, какое место у тебя в этом круговороте информации. В каком виде и куда должно приходить новье? На почту? На телеграф? В приложение? В фидо?
Я советую еще раз перечитать всю статью, там ровно об этом и говорится. По крайне мере, веб-разработчику с минимадбным стажем должно хватить с лихвой данных мной ссылок на JSON, остальным они в любом случае полезны не будут.
Ещё раз всё прочитал. Понял, что на выходе получиться очередная «куча мала, вид сбоку» замкнутая сама на себе. Вот я пользователь, который хотел бы получать обновления базы. Как это будет выглядеть? Как будет происходить движения информации? Что я получу по факту?
Так же не раскрыта тема внутренней структуры твоей базы. Начинать нужно её детальной проработки. Это большая часть (но не весь) ответа на вопрос «что хотим получить на выходе?».
Проблема забора информации из других источников решается очень просто. Для этого придется для каждого внешнего источника вести свою базу. Будет это полноценная база или только индексный список, вопрос далеко не самый важный. Но новые данные однозначно должны быть храниться полностью и их структура максимально приближаться к утвержденной для основной базы. После чего отдельный скрипт проверят информацию на дупы, на полноту и в случае чего пытаться сам найти недостающее. Если информация прошла фильтрацию (то есть уникальна) и полна на 100% она автоматически добавляется в основную базу. Иначе подаем сигнал админу, что есть новая инфа, но с ней возникли проблемы «иди, разбирайся в ручном режиме». Возможны варианты, например пришли новый скриншоты или описание для программы которая уже есть в основной базе. Но это все уже твои проблемы, раз взялся за это неблагодарное дело.
Мне же непонятно какое место у меня в этом круговороте информации? Я бы не отказался получить новьё, и желательно оно должно приходить сама, без телодвижений с моей стороны (как это происходит в FIDO).
Моя ремарка в том, что ИМХО к постановки и решению задач подошли не с того конца.
ИМХО озвученные вами проблемы носят исключительно технический характер. Задачу нужно сократить до пунктов:
1. Сбор всей имеющейся информации из разных баз в единую.
2. Дальнейшее единовременное обновление информации на всех ресурсах.
Без пункта 1 второй невозможен, а без второго первый теряет большую часть смысла, так как рано или поздно мы вернемся к нему. Следовательно решать их нужно комплексно.
Опыт FIDO может помочь решить именно второй пункт, и да же расширить его до рассылки информации всем подписчикам (а их может быть сотни и тысячи, и список может постоянно меняться). Главное проблемой при решения п.2 будет то, что нужно договариваться со всеми участниками, о механизмах обмена и синхронизации данных. Что будет скорее весьма проблемно, так как на спекки всегда отдельные группы и индивиды стремились тянуть одеяло на себя. И согласись, всё это выводит разрешение задачи п.2 далеко за рамки технических решений.
Если договориться не удастся (в чем лично я убежден), нужно создать несколько зеркал на разных площадках (так что бы они одновременно не накрылись) с обновлением информацией между собой. А механизм доступа к потокам обновляемой информации сделать отрытым, так что бы любой желающий мог не только получать новую информацию, но сам её генерировать (вот тут и нужен опыт FIDO).
Первый пункт, решается классическими методами объединения баз. Собственно их уже описали.
Его трудоемкость зависит от качества структуры и описания исходных баз данных. Чем оно ниже, тем выше трудоемкость, вплоть до ручной разборки. Но всё равно это чисто технические решения (да, весьма геморройное).
Но за «трудоемкость» я сказать не могу, так как не обладаю информацией о структурах исходных баз данных.
Часть из них я так же слили себе себе на комп, путем полного копирования сайтов wget'ом. Но мои личные задачи отличны о ведения архива программ.
Это к чему такая ремарка? Я не понял, честно говоря.
Все описанные проблемы сугубо прикладного плана, то есть на бумаге их можно решать хоть в фидо, хоть в статском физкультурнике, но без написания конкретного программного решения в данном случае всей этой болтовне грош цена.
Теоретиков и концептологов объединения баз кругом хоть жопой жуй, а что имеем по факту?
* Старый WOS на кодобазе двадцатилетней давности
* Новый WOS, который за три или четыре года не готов показать ни одной программы
* ZXAAA, в котором даже админки нет
* ZXDB, который не является платформой, а являет собой просто отдельный дамп базы
* Sinclair Computing, который является принципиально фронтендом для ZXDB, то есть не предполагает администрирования и пополнения.
* ZXN, который продвинулся дальше всех, но едва ли ставит перед собой цели шире демоархива
* Virtual TR-DOS, идеологически застрявший году эдак в 1998ом.
Если все такие заслуженные элитные сценеры, то где наш аналог CSDB?
Ну, не знаю я истории FIDO, и что я должен был сделать?
Всё бросить и надеяться, что кто-то со знанием истории возьмется за задачу? Не возьмется, пиздеть не камушки ворочать.
Пойти читать архивы замшелых переписок каких-то чуваков из фидо? Как это приблизит к написанию кода?
Что я должен делать, чтобы не изобретать велосипед? Пойти в велосипедный магазин и купить? Где-то продают готовые базы спектрумовского софта, или что?
Конкретику, пожалуйста.
Это все хорошо. Но было бы не плохо просто знать историю. ВСЕ проблемы озвученные здесь решены много лет назад в FIDO для синхронизации баз BBS. Смысл было изобретать велосипед?
Дима, да — такого не хватает, лично мне — очень. причём в идеале бы онлайн-скрипт, которому можно скормить фонт (768), а на выходе он упорядочит символы по плотности пикселей, выделив те (соседние), в которых плотность совпадает
Таким образом, внутренняя структура базы не играет особой роли, играет роль структура JSON-ответа.
Вести отдельную базу для каждого источника — это непрактично, но индексный список уже есть. Новые данные уже приближаются к структуре базы, именно для этого внутренние парсеры и нужны.
Отдельный скрипт-интегратор уже проверяет информацию на дупы и уже пытается найти и подвязать информацию из имеющегося набора.
Стопроцентной полноты в реальном мире не существует, есть минимальный набор, без которого нет смысла что-то импортировать. Это уже делается, именно об этом и есть статья.
Сигнал админу — это непрактично, никто на зарплате не работает, чтобы информация месяцами дожидалась, когда у админа дойдут руки. Поэтому импортируем что есть, а потом разруливаем проблемы.
Мне тоже непонятно, какое место у тебя в этом круговороте информации. В каком виде и куда должно приходить новье? На почту? На телеграф? В приложение? В фидо?
Я советую еще раз перечитать всю статью, там ровно об этом и говорится. По крайне мере, веб-разработчику с минимадбным стажем должно хватить с лихвой данных мной ссылок на JSON, остальным они в любом случае полезны не будут.
Так же не раскрыта тема внутренней структуры твоей базы. Начинать нужно её детальной проработки. Это большая часть (но не весь) ответа на вопрос «что хотим получить на выходе?».
Проблема забора информации из других источников решается очень просто. Для этого придется для каждого внешнего источника вести свою базу. Будет это полноценная база или только индексный список, вопрос далеко не самый важный. Но новые данные однозначно должны быть храниться полностью и их структура максимально приближаться к утвержденной для основной базы. После чего отдельный скрипт проверят информацию на дупы, на полноту и в случае чего пытаться сам найти недостающее. Если информация прошла фильтрацию (то есть уникальна) и полна на 100% она автоматически добавляется в основную базу. Иначе подаем сигнал админу, что есть новая инфа, но с ней возникли проблемы «иди, разбирайся в ручном режиме». Возможны варианты, например пришли новый скриншоты или описание для программы которая уже есть в основной базе. Но это все уже твои проблемы, раз взялся за это неблагодарное дело.
Мне же непонятно какое место у меня в этом круговороте информации? Я бы не отказался получить новьё, и желательно оно должно приходить сама, без телодвижений с моей стороны (как это происходит в FIDO).
1. Объединить все базы в одну.
2. Раздавать всем желающим через внешнее API.
Проблема такого подхода в его централизации, но децентрализованное решение писать ни у кого желания нет, это факт, поэтому делаем как можем.
ИМХО озвученные вами проблемы носят исключительно технический характер. Задачу нужно сократить до пунктов:
1. Сбор всей имеющейся информации из разных баз в единую.
2. Дальнейшее единовременное обновление информации на всех ресурсах.
Без пункта 1 второй невозможен, а без второго первый теряет большую часть смысла, так как рано или поздно мы вернемся к нему. Следовательно решать их нужно комплексно.
Опыт FIDO может помочь решить именно второй пункт, и да же расширить его до рассылки информации всем подписчикам (а их может быть сотни и тысячи, и список может постоянно меняться). Главное проблемой при решения п.2 будет то, что нужно договариваться со всеми участниками, о механизмах обмена и синхронизации данных. Что будет скорее весьма проблемно, так как на спекки всегда отдельные группы и индивиды стремились тянуть одеяло на себя. И согласись, всё это выводит разрешение задачи п.2 далеко за рамки технических решений.
Если договориться не удастся (в чем лично я убежден), нужно создать несколько зеркал на разных площадках (так что бы они одновременно не накрылись) с обновлением информацией между собой. А механизм доступа к потокам обновляемой информации сделать отрытым, так что бы любой желающий мог не только получать новую информацию, но сам её генерировать (вот тут и нужен опыт FIDO).
Первый пункт, решается классическими методами объединения баз. Собственно их уже описали.
Его трудоемкость зависит от качества структуры и описания исходных баз данных. Чем оно ниже, тем выше трудоемкость, вплоть до ручной разборки. Но всё равно это чисто технические решения (да, весьма геморройное).
Но за «трудоемкость» я сказать не могу, так как не обладаю информацией о структурах исходных баз данных.
Часть из них я так же слили себе себе на комп, путем полного копирования сайтов wget'ом. Но мои личные задачи отличны о ведения архива программ.
Все описанные проблемы сугубо прикладного плана, то есть на бумаге их можно решать хоть в фидо, хоть в статском физкультурнике, но без написания конкретного программного решения в данном случае всей этой болтовне грош цена.
Теоретиков и концептологов объединения баз кругом хоть жопой жуй, а что имеем по факту?
* Старый WOS на кодобазе двадцатилетней давности
* Новый WOS, который за три или четыре года не готов показать ни одной программы
* ZXAAA, в котором даже админки нет
* ZXDB, который не является платформой, а являет собой просто отдельный дамп базы
* Sinclair Computing, который является принципиально фронтендом для ZXDB, то есть не предполагает администрирования и пополнения.
* ZXN, который продвинулся дальше всех, но едва ли ставит перед собой цели шире демоархива
* Virtual TR-DOS, идеологически застрявший году эдак в 1998ом.
Если все такие заслуженные элитные сценеры, то где наш аналог CSDB?
Ну, не знаю я истории FIDO, и что я должен был сделать?
Всё бросить и надеяться, что кто-то со знанием истории возьмется за задачу? Не возьмется, пиздеть не камушки ворочать.
Пойти читать архивы замшелых переписок каких-то чуваков из фидо? Как это приблизит к написанию кода?
Что я должен делать, чтобы не изобретать велосипед? Пойти в велосипедный магазин и купить? Где-то продают готовые базы спектрумовского софта, или что?
Конкретику, пожалуйста.
Посмотреть пока только тут: events.retroscene.org/ooc2018
Обзор работ: hype.retroscene.org/blog/graphics/893.html
может даже логичнее вот так.
Буквы палитрой сложнее нарисовать, нужно скрипт колхозит. Если идея кажется вменяемой, то сделаю.