AV>> Я уже неоднократно говорил, что единственное разумное применение AV>> подобной технологии состоит в распространении относительно небольших AV>> .torrent-файлов, которые в настоящее время вытесняются magnet-ссылками, AV>> что делает файлэхи окончатеньно ненужными.
DR>>> А если иногда и большие - то только внешние ссылки без вариантов.
AV>> Да, причем я предпочел бы magnet-ссылки.
SS> Magnet-ссылка зависит не только от содержимого, но и от имени файла, SS> верно?
SS> Magnet-ссылку нельзя просто сгенерировать по имени и содержимому файла, SS> верно? Всё же сперва надо сгенерировать .torrent в каком-то файлообменном SS> сервенте, который притом готов будет стать на раздачу, а затем уж по SS> .torrent-файлу создать magnet-ссылку. (Не то magnet-ссылка будет, но будет SS> неработоспособною.)
SS> То и другое как-то не радует в контексте иллюстрирования Фидонета.
Я только что заметил, что девять дней назад (6 сентября) я всего лишь указал на более или менее очевидные недостатки magnet-гиперссылок, которые сделают, на мой взгляд, неудобным применение их для иллюстрирования Фидонета.
Однако, критикуя magnet, мне следовало бы одновременно предлагать какую-нибудь альтернативу. Какое другое средство лучше подходит для хранения иллюстраций (картинок, звукозаписей, видеозаписей), однако лишено недостатков торрентовой magnet-ссылки? Для преодоления этих недостатков адрес файла должен зависеть только от содержимого файла, но не зависеть от имени файла, не зависеть от его соседей по одновременной раздаче, не зависеть от его расположения в подпапке при одновременной раздаче, и так далее.
Я не предложил никакой хорошей альтернативы, потому что 6 сентября я не знал никакой хорошей альтернативы. Теоретически я мог бы вспомнить о гиперссылках ed2k, которыми пользуется файлообменные сети ed2k и Kad, населённые аналогами программы eMule; однако эти файлообменные сети и программы не популярны, они не имеют потенциала развития, это бесперспективняк. Притом такие программы большей частью имеют только графический интерфейс (GUI), так что трудным делом было бы налаживание интерфейса между ними и фидонетовским софтом для подачи им таких команд, как 'опубликуй файл и дай адрес' или 'получи файл по его адресу'.
Сейчас мне, однако же, известна такая альтернатива. Я узнал о том, что ведётся разработка распределённой файловой системы IPFS.
Я пришёл к выводу, что внутреннее устройство IPFS выглядит продуманным, в него заложены возможности для апгрейда со временем (например, по мере устаревания использующихся методов хэширования файлов и методов адресации узлов сети) ── следовательно, смерть от внутренних причин не грозит этой файловой системе.
Также я пришёл к выводу, что движуха вокруг IPFS выглядит деятельною, так что появление программ с хорошими интерфейсами (которыми могло бы пользоваться также и фидонетовское программное обеспечение) в известной мере состоялось уж, а в ближайшем будущем появятся и новые, существенно лучше прежних, в том числе способные работать внутри браузера или веб-сервера.
Краткий вывод будет таков: хранение иллюстраций в IPFS способно заменить собою хранение иллюстраций в файлэхах в той же мере, в какой хранение иллюстраций в файлэхах способно заменить собою хранение иллюстраций в UUE внутри сообщения. Мера эта вот какова: побольше технические возможности, но меньше популярность и надо доустанавливать софт, причём некоторого необходимого софта ещё вообще нет в природе и его надо сочинить.
Этот краткий вывод я сейчас поясню более развёрнуто в двух последующих абзацах.
У файлэх больше технические возможности, чем у ююков (нет ограничений объёма со стороны старых эхотоссеров, хабы не слишком возбуждаются на объём файлов, каждый файл можно отдельно брать на FTP-зеркалах или перезапросить у аплинка, если файлэха у аплинка не passthrough и не была подвергнута стиранию старых файлов), но меньше популярность (на узле может вообще не быть файлэх, может быть не оформленною подписка на конкретную файлэху, может быть passthrough, или ограниченный по времени архив файлов, или ограниченный объём архива файлов, или оба эти ограничения вместе) и надо доустанавливать софт (файлэхопроцессор, а также гипертекстовый фидобраузер для отображения в эхах иллюстраций, взятых из файлэх), причём некоторого необходимого софта ещё вообще нет в природе и его надо сочинить (речь идёт о гипертекстовом фидобраузере с поддержкою файлэх).
У системы IPFS больше технические возможности, чем у файлэх (нет устаревшего ограничения 8.3 на имена файлов, нет проблемы затирания файла одноимённым новым файлом, нет проблемы удвоенных усилий по распространению одинаковых файлов с разными именами или по разным файлэхам, одинаковые файлы одноимённы несколько лет и одинаково переменяют их имя во время перехода сети к употреблению нового хэша, равномерно распределяется нагрузка по раздаче файла без перенапряжения центральных хабов или первого публикатора, файл получают только желающие и нет обязывающей тематической подписки, старт файлораздачи не влечёт организационные усилия по созданию и подъёму на файлэхобон и последующему модерированию новой файлэхи даже в случае раздачи файлов на некоторую новую, ещё небывалую тему), но меньше популярность (сейчас нигде в Фидонете нет поддержки IPFS, а ещё будут проблемы узлов и пойнтов, не готовых начать поддержку IPFS, не имеющих у себя поддерживаемой IPFS операционной системы, не имеющих постоянного подключения к Интернету и т. п.) и надо доустанавливать софт (как поддержку IPFS, так и гипертекстовый фидобраузер для отображения в эхах иллюстраций, взятых из IPFS), причём некоторого необходимого софта ещё вообще нет в природе и его надо будет сочинить (речь идёт о гипертекстовом фидобраузере с поддержкою IPFS).
Mithgol the Webmaster. ═[Mithgol.Ru]═[FGHI]═[Ru.Mozilla]═[Team А я меняю subj]
--- Знаешь ли ты, Alexey, что "Кёне" пишется через "ё"? * Origin: Ты можешь ── но это не ускорит обретение тобою нирваны! (2:50/88)
