LINUX.ORG.RU

P2P-соцсеть. Вопрос сохранения страниц по ссылкам.

 , , ,


0

3

Продолжая старую тему p2p-соцсети.

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

Сейчас этот вопрос у меня решается только отчасти — я храню в базе данных снипет (заголовок, описание, оконка/превью) и показываю в сообщении. Но давно стоит вопрос архивирования страниц по ссылкам. Раньше я думал больше о тупом сохранении в архив страницы со всем содержимым, скажем, через wget, но в общем случае задача шире и сложнее.

Раз уже мы всё храним в p2p (на самом деле сейчас — только аттачи, и только в конкретной IPFS, но хранение в p2p и целиком топиков/блогов/комментариев и в других хранилищах — совсем не вопрос) хочется хранить в p2p и архивы чужих страниц.

И вот тут у меня нет готового хорошего решения. Интернет так и не родил единый стандарт на хранение целиком страницы одним файлом.

MAF так и остался неподдерживаемым форматом Мозиллы.

MHTML, хотя и является RFC-стандартом, никто кроме Оперы его реально не поддерживал... Хм. А вот дальше интересно. Пока писал сообщение, решил проверить поддержку его в браузерах. Да, Опера его уже не сохраняет, как раньше, но показывает. Как и IE с Хромом. Не показывает только Firefox. Это, конечно, минус, но уже терпимый. Firefox стремительно теряет позиции, так что удобством остатков его пользователей можно пренебречь — в конце концов, придумают расширение :) Зато, всё же, стандарт.

Третьим вариантом я видел HTML, переписанный на встраивание всех используемых им ресурсов (картинки, стили) во встроенной форме (src=«data:image/png;base64...»). Это самый геморройный вариант, ибо тонны подводных камней, начиная от ограничений по размерам ресурсов, кончая встраиванием JS и CSS.

Четвёртый вариант ужасен — это хранение всех HTML-ресурсов в p2p раздельно с конвертацией ссылок на них.

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

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

...

P.S. А рабочее название проекта пока я оставляю всё равно Infonesy. Сам вижу недостатки, но ничего лучшего так пока и не нашёл :)

P.P.S. Текущий статус системы — однонаправленная гетерогенная репликация форума, поток сообщений/информации через BTSync по ключу, аттачи — в IPFS. В принципе, включение двунаправленой связи дело одного часа работы, но пока откладываю, так как придётся до срока отвлекаться на реализацию идеологии одностороннего ограничения на свободу постингов и т.п. Скорее всего, раньше продолжу развитие гетерогенности, подключив несколько концептуально разных источников (LiveStreet, Wordpress, Twitter).

★★★★★

Firefox стремительно теряет позиции, так что удобством остатков его пользователей можно пренебречь

вот это сейчас обидно было:)

Интернет так и не родил единый стандарт на хранение целиком страницы одним файлом

можно жать любым любимым быстрым алгоритмом в архив, например

это хранение всех HTML-ресурсов в p2p раздельно с конвертацией ссылок на них

кмк, самый правильный вариант. Есть же metada в magnet-торренте, можно по ней строить HTML со всеми ресурсами, динамически

fang90 ★★★★★
()
Ответ на: комментарий от fang90

вот это сейчас обидно было:)

А кому сейчас легко! :)

можно жать любым любимым быстрым алгоритмом в архив, например

Задача стоит ткнуть в ссылку и получить страницу. Вариант «скачать, распаковать, посмотреть» — не годится. Есть, конечно, вариант, качать/распаковывать на ноде и клиентам отдавать сообщение с подменённой ссылкой, но, ИМХО, криво это. MHTML тут смотрится лучше.

По приколу — пример этой страницы в виде MHTML уже сразу в сети IPFS:
http://gateway.ipfs.io/ipfs/QmejRbVs3zfoWrbfWnqFj37btwSHYgdT3SSSnv4rsVb6Cq

И вот, сразу проблема, блин. IPFS не знает про MIME-тип MHTML :-/ Отдаёт плейн-текстом...

кмк, самый правильный вариант.

Две проблемы сразу:

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

— Важно, чтобы p2p-хранилище корректно отдавало MIME встроенных объектов. Скажем, IPFS отдаст CSS и JS с mime=text/plain. JS при этом обработается браузером корректно, а вот CSS — нет.

Вообще, проблема очень близка к проблеме отображения MHTML. Поковыряться, что ли, в сорцах IPFS на тему MIME? У меня руки разбегаются, всё это самому делать :)

KRoN73 ★★★★★
() автор топика

Сохранение страницы в одном файле это некорректная задача, т.к. противоречит сути HTTP и HTML. Лучше думай, как сохранить эту суть (кто угодно может ссылаться куда угодно), ибо она сделала интернет тем, что он есть сейчас. Можно решать частные задачи, сохранять 90% страниц и тд, но это уже попытка натянуть сову на глобус.

Legioner ★★★★★
()
Ответ на: комментарий от Legioner

Сохранение страницы в одном файле это некорректная задача, т.к. противоречит сути HTTP и HTML.

Чем же? Я согласен, что она противоречит сути REST, но как оно может противоречить сути HTTP (отдать по запросу контент) или HTML (отрендерить изображение по текстовому источнику)?

Лучше думай, как сохранить эту суть (кто угодно может ссылаться куда угодно)

Я и решаю эту задачу. Человек ссылается на чужой сайт — в архиве системы сохраняется содержимое сайта в момент ссылки. Кто угодно ссылается куда угодно, а контент сохранится единообразно и с настраиваемой надёжностью хранения.

Минус тут только в том, что на начальном этапе я делаю ставку на одну IPFS, хотя, по хорошему, нужно подключать ещё Freenet, GNUNet и т.п. Но тогда точно не взлетит. Вот чему научил опыт подобных проектов, начинать надо с того, что пощупать можно уже сегодня и что можно показать в работающем виде завтра. Пусть даже это будет пока только упрощённая концепция.

KRoN73 ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.