My comment to an entry 'Пора выпускать из пробирки лёд-9? (1/x)' by bacr
Тоже размышлял на эти темы ещё с 2010, когда начал заниматься темой интеграции данных, где необходимость поддержки альтернативных миров/версий естественным образом приводит к требованиям децентрализации. Основные выводы таковы:
1. Для обмена данными наиболее важны не протоколы, а форматы. Желательно бинарные бандлы с документами, где на каждом уровне поддерживаются произвольные бинарные вложения (с дедупликацией в пределах бандла), метаданные и подписи. И не важно, как они пришли - через решения на базе DHT, на флэшке или были скачаны с обычного сайта как "библиотека научных статей такого-то автора". Если контент подходит под критерии интересующего, а подписи под критерии приемлемого, значит данные полезны. API запросов, подписок и публикаций, а также их транспортные протоколы, могут различаться. Например, таким разным узлам как "база знаний компании" и "сервер агрегации обновлений" нужны разные их подмножества, и если разработчики стандарта увлекаются одним из случаев, то стандарт оказывается непригодным для других. Кстати, независимость формата и протоколов успешно работала ещё в фидо, где можно было раздельно выбирать мейлеры (с разным транспортом) и тоссеры. А вот в современных попытках решений на протоколы конкретно залипают.
2. Необходима система идентификации многоверсионных данных. Однако, подходы со случайными айди и синтетическими подобиями файловой системы создают лишний когнитивный мусор. Более того, для многих данных (таких как посты или комментарии в соцсетях) заранее неизвестно, будут ли они перезаписаны новыми (или дописаны альтернативными) версиями. Решение я нашёл в 2017 году, подробнее об этом в https://justy-tylor.livejournal.com/252597.html В частности, таким образом легко разделяются деревья обновлённых/альтернативных версий статей для разных сущностей с одинаковыми именами в вики (или наоборот, продолжается то же дерево, когда меняется основное имя статьи).
3. Начинать следует не с сети, а с локального пользователя. Может он создать у себя заметку о недавно прочитанной научной публикации и прикрепить туда pdf самой публикации через криптохэш (с учётом этой ссылки в локальном content-addressable storage)? Если да - хорошо, это идеально масштабируется до децентрализованной многопользовательской системы (как пример - ранние стадии развития git). Если нет, и требуются некие действия с сетью, либо меняется идентификация документа между локальным и "опубликованным" представлением, то неминуемо повторение сегодняшней веб-помойки.
View the entire thread this comment is a part of
1. Для обмена данными наиболее важны не протоколы, а форматы. Желательно бинарные бандлы с документами, где на каждом уровне поддерживаются произвольные бинарные вложения (с дедупликацией в пределах бандла), метаданные и подписи. И не важно, как они пришли - через решения на базе DHT, на флэшке или были скачаны с обычного сайта как "библиотека научных статей такого-то автора". Если контент подходит под критерии интересующего, а подписи под критерии приемлемого, значит данные полезны. API запросов, подписок и публикаций, а также их транспортные протоколы, могут различаться. Например, таким разным узлам как "база знаний компании" и "сервер агрегации обновлений" нужны разные их подмножества, и если разработчики стандарта увлекаются одним из случаев, то стандарт оказывается непригодным для других. Кстати, независимость формата и протоколов успешно работала ещё в фидо, где можно было раздельно выбирать мейлеры (с разным транспортом) и тоссеры. А вот в современных попытках решений на протоколы конкретно залипают.
2. Необходима система идентификации многоверсионных данных. Однако, подходы со случайными айди и синтетическими подобиями файловой системы создают лишний когнитивный мусор. Более того, для многих данных (таких как посты или комментарии в соцсетях) заранее неизвестно, будут ли они перезаписаны новыми (или дописаны альтернативными) версиями. Решение я нашёл в 2017 году, подробнее об этом в https://justy-tylor.livejournal.com/252597.html В частности, таким образом легко разделяются деревья обновлённых/альтернативных версий статей для разных сущностей с одинаковыми именами в вики (или наоборот, продолжается то же дерево, когда меняется основное имя статьи).
3. Начинать следует не с сети, а с локального пользователя. Может он создать у себя заметку о недавно прочитанной научной публикации и прикрепить туда pdf самой публикации через криптохэш (с учётом этой ссылки в локальном content-addressable storage)? Если да - хорошо, это идеально масштабируется до децентрализованной многопользовательской системы (как пример - ранние стадии развития git). Если нет, и требуются некие действия с сетью, либо меняется идентификация документа между локальным и "опубликованным" представлением, то неминуемо повторение сегодняшней веб-помойки.
View the entire thread this comment is a part of