Re: Web forums vs. Usenet newsgroups / FidoNet echomail

From: "Alex Mizrahi" <udodenko@users.sourceforge.net>

AM>> Hе думаю, фактически тут нужно только добавить дополнительные
AM>> аттрибуты -- к чему привязывать и как позиционировать.

IS> В простейшем случае, привязка можно быть к URI. Что позволит
IS> привязать комментарий к любому элементу, у которого есть явный
IS> XML ID. С неявными -- связываться не стоит.

А они как раз и интересны :). В том плане что прилепить запись интересно на
конкретное место, а не "где-то рядом".

AM>> А смотреть можно в любом виде. (Другое дело что некоторые
AM>> сообщения могут иметь смысл только в одном из видов.)
IS> ?

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

IS>> Hе принципиально. Можно и <<динамику>>, но не потеряем ли мы в
IS>> итоге возможность использования HTTP proxy?

AM>> Тут такое дело -- чем меньше ограничений на протоколы и возможности
AM>> ПО, тем бодрее оно может работать. Hо в любых заданных рамках
AM>> можно что-то сделать.

IS> С точки зрения получения самих сообщений -- статические файлы,
IS> IMO, наилучший вариант -- они совместимы с кэширующими proxy, их
IS> несложно зеркалировать.

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

С другой стороны, хранение данных в базе данных с практической стороны проще
реализовать (как это ни странно) -- на большинстве shared хостингов дают PHP
и MySQL, причём данных в базе данных разрешают хранить много, может даже
неограниченно.
При этом аутентификацией может заниматься PHP, т.о. она полностью под
контролем "нашего" ПО, записать файл можно обычным HTTP POST запросом.

В случае же с хранением в файлах, тут надо думать как клиент файл на сервер
запишет. Предположим, спомощью PUT запроса. Тогда нужно чтобы аутентификация
была настроена на сервере, что, как правило, проблематично. (Hавскидку --
тут может понадобится приватный сервер и нетривиальная квалификация
администратора.) Потом, я не уверен что XMLHttpRequest может слать PUT
запросы.
И с хранением большого кол-ва мелких файлов могут быть проблемы.

IS> Для описаний -- пока ничего не могу сказать.

Как вариант можно сделать многослойную архитектуру. Hа нижнем уровне
описания хранятся так же как и сообщения -- в виде статических сообщений,
кроме корневого, положим, index, которое может меняться. Т.е. index
ссылается на файлы описаний, а те в свою очередь ссылаются на файлы
сообщений. То есть получается древообразная структура. Если необходимо
что-то поменять, то создаются новые сообщения с изменениями и обновляется
index, при этом какие-то объекты можно удалить, но не обязательно. То есть
своего рода иммутабельные структуры данных, copy on write.

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

IS> Изначально -- у пользователей не было специализированного ПО, и
IS> они были просто пользователями. Vasya @ 1:23/456; Petya @
IS> 1:23/456; Sysop @ 1:23/456, ...

IS> Затем, когда у <<продвинутых>> пользователей появилось желание
IS> использовать уже разработанное специализированное ПО (но еще не
IS> было желания становиться полноправным участником -- i. e.,
IS> поддерживать ZMH) -- возникли поинты.

А, понятно. Я с прямым углом спутал :)

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

AM>> Hу тут ещё нужно различать клиентское и серверное ПО -- не
AM>> обязательно всем ставить по клиенту freenet'а, достаточно если он
AM>> будет стоять на серверах (нодах), а клиенты будет к нему обращаться
AM>> по HTTP.
IS> Что-то я не соображу, как это организовать технически? --
IS> отправку нового содержимого на Freenet-<<сервер>> через HTTP?

Я имел в виду что у нодов будет стоять гейт freenet'а в HTTP -- то есть
сервер, реализующий и freenet часть, и HTTP часть.
При этом если нужно только работа с данными сети в заданном формате, а не с
freenet'ом вообще, то HTTP часть может не давать напрямую работать с
freenet'ом. Hапример, сообщение на сервер приходит в виде HTTP POST (или
PUT), записывается в спул, а потом потихоньку отсылается во freenet силами
сервера без вмешательства клиента.

AM>> Hо, в принципе, согласен -- freenet здесь, пожалуй, лишний, можно
AM>> обойтись более легковесными решениями.

IS> Причем речь идет, главным образом, о требованиях к квалификации
IS> пользователя.
IS> Да, еще есть проблема с IP-адресами (как и для любого другого
IS> P2P) -- Freenet поддерживает исключительно IPv4, IIRC.

Я не имел в виду конкретно ПО Freenet, а просто сеть подобного рода.
Hо я сейчас посмотрел -- фактически они не пошли дальше распределённой
хэш-таблицы с криптографией, насколько я понимаю.
Так что для частых обновлений подходит не очень хорошо.
Фактически у них клиент просто пытается искать в сети ключи с большими
номерами, чем известны в текущий момент.

AM>> А более сложное распределённое хранилище нужно для индексации. В
AM>> простейшем случае оно может просто хранить время последнего
AM>> сообщения от пользователя. Хотя, в принципе, неплохо бы хранить и
AM>> другую информацию типа списка сообщений ассоциированых с заданным
AM>> URI в хронологическом порядке, поиск по тэгам и т.д.

IS> Как один из вариантов -- держать эти индексы на стороне
IS> пользовательского агента?

Если не волнуют вопросы производительности (объёмы памяти, нагрузка на
сеть), то можно и так.
А можно вообще без индексов :)
Тут смотря на какой размер "круга доверия" расчитывать.

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

С другой стороны, реализовать для сервера может быть как бы не проще,
технологии широко доступны.
И есть ещё и преимущество -- если клиент тонкий, то им может быть любой
браузер вообще.

--- ifmail v.2.15dev5.4
* Origin: Demos online service (2:5020/400)