Проблема 404

[vitus_wagner]

Вот тут jolaf расстраивается по поводу исчезновения полезной информации из интернета.

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

Осталось только взять и написать. К сожалению, как раз до этого руки хронически не доходят.
Хорошо хоть всю криптографическую базу недавно доделал. Но тестов на модуль identity (единстыенный из написанных) так и не написал пока.

Comments

[angry-elf.livejournal.com]

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

[zaharchenko]

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

Хотя конечно может быть самое правильное будет, это отлавливать изменения в DOM'e, натравливать на них какой-нибудь xmldiff(от того же react например) и хранить себе спокойно отдельно и оригинал, и diff, а ключом первичным датувремя и урл считать. Зря я наверно боюсь такое замутить.

[angry-elf.livejournal.com]

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

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

[zaharchenko]

>плохие примеры. На них ссылаться сложно, а это было первичным посылом.
как раз хорошие - если можно нормально их сохранить, остальное и подавно

Я так и не понял чем скриншот отличается от HTML'ки, ну или лучше даже MHTML/webarchive? А дата "снятия" может быть, а скорее должна быть, вообще у чего угодно.

[angry-elf.livejournal.com]

Парсер жаваскрипта через 10 лет, например, неправильно запустит скрипт из архива.

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

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

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

А для конкретной информации давно есть link href alternate с xml-based форматами, rdf-разметкой. Т.е. высосано из пальца и не существует в реальном мире :)

Был вот gopher, да весь вышел... А остальное всё - профанация.

[zaharchenko]

>Ну и я про хэштэг сказал. Уже давно любят им контент кодировать.
Сорри за занудство, хэштеги в твитере и инстаграме, а в урле просто хэш или правилнее даже fragment identifier, но не суть важно, главное мы о одном и том же. Так вот хэш не виноват, на один и тот же урл, даже без хэша, спокойно можно получить два разных контента, есть как минимум куки. И тут не доконца понятно что делать.

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

[angry-elf.livejournal.com]

Мне тоже не нравятся изображения, но это самый устойчивый во времени формат.

Может тогда pdf с текстом внутри? Т.е. что б и изображение, и индексабельное содержимое? Можно даже пойти дальше - три уровня - векторное изображение, растровое изображение (вдруг формат вектора будет утерян?) и текстовый эквивалент. И щедрая горсть метаданных, для статистических анализаторов 23-го века.

[zaharchenko]

Pdf c ходу кажется хуже html'я, как минимум всё вокруг htmlной ± нормально текстовым редактором читается, и кажется мне что с долгожитием у html'я получше будет.

[angry-elf.livejournal.com]

У PDF есть достаточно гарантированная способность приведения бинарного представления в визуальное отображение. У html же с этим проблемы. Если со старым (до html5) это ещё более-менее решено (путём миллиона костылей), то с html5 всё меняется в реальном времени, как заявлено в стандарте и в, практически единственном, референсном браузере.

[vitus_wagner]

А нам не нужно визуальное отображдение. Нам нужно сохранение смысла.
В смысле, например, аудиального отображения, или автоматизированного перевода html сильно удобнее pdf.

[angry-elf.livejournal.com]

У PDF же есть версии, которые позволяют найти хотя бы ближайшую, по версии, библиотеку, превращающую блоб в картинку.

Версии же в html, как правило, не релевантны вообще ничему. Как верстальщик закодировал на текущий момент, не более.

[angry-elf.livejournal.com]

Ещё вот пример, что б далеко за ними не ходить - данная страница.
Содержимое её отличается от активности внутри, при этом урл не меняется, даже хэштэг не дописывается. По кнопке expand содержимое страницы меняется. Если сторонний сервис сохранит по урлу - 90% комментариев видно не будет.

Так что только скриншоты. Скриншоты же разные по контенту должны сохраняться, вдруг они разные части страницы показывают?

А не скриншоты - только для заведомо отпарсенных parseable (как это по русски?) сущностей. Например, для ютубовских видео (и то, когда комментарии там не нужны).

[zaharchenko]

Вот я о том же, что урл это далеко не первичный ключ, наверно всё таки правильнее всего его рассматривать как первичный ключ какого множества схожих "страниц", а внутри уже хранить все страницы с датой среди которых уже только руками находить подходящую для каждого конкретного случая.

А как, а тем более как эффективно, хранить это уже другой совмем вопрос.

[angry-elf.livejournal.com]

Есть ещё проблема, когда тыщи (миллионы?) разных урлов ссылаются на идентичный (вплоть до баннеров) контент.

[zaharchenko]

Ну эта другая проблема, она кстати на всяком бинарном да css/jsном может выплыть, тут не надо лукавить, и при физическом хранение адресовать уже по хешам.

[vitus_wagner]

Нифига не один файл на одну страницу. Как правило, содержательные html-странцы имеют длину в сотни раз превышающую длину экрана.

А графических программ способнрых справитсья с картинкой 1920x108000 на свете очень мало. (да и большая часть графических форматов. как ни странно имеет ограничение в 65535, а то и 32767 пикселов вертикального размера).