= ru.ftn.develop (2:5030/1104.666) ============================================
 Msg  : 52 of 52                            Snt Loc
 From : Eugeny Ipatov                       2:5030/1104.666 22 Апр 07  23:19:52
 To   : Mithgol the Webmaster
 Subj : Перспективы развития гипертекстового Фидонета
===============================================================================
Привет, Mithgol!

22 Апр 07 08:30, ты писал(а) Vitaly Petrov:

 VP>> В общем, это не так сложно в реализации, так как некоторая
 VP>> стартовая база уже готова. Так зачем делать area:// ?
 MtW> Единая форма адресации ресурсов Фидонета всё равно необходима, а иначе
 MtW> как же гиперссылки ставить? Если только ты не намекаешь, что
 MtW> воображаемый FTN-редактор на PHP должен стоять только на одном сайте,
 MtW> и все ссылки тоже туда должны вести обязательно... Hо это не свобода.
 MtW> Это уже есть на Гугле, созданном еврейскими расовыми жидами. Google
 MtW> Groups называется. Это не интересно. Денег на рекламе контекстной эдак
 MtW> можно заработать, а пользы от этого для Фидонета не будет.

Тогда уж и я поучаствую в обсмыселках :)

Я так понимаю, что гиперссылки должны работать таким образом:
1. если сообщение есть в базе - просто показывать его
2. если сообщения в базе нет - то задавать команду %rescan на эху (это простой 
вариант, не требующий коренного изменения ПО), либо давать запрос на получение 
конкретного сообщения (требует модификации ПО). Hо что-то мне не нравится в 
идее с выборочным получением сообщения...

Оффлайновая работа с одной стороны является для ФИДО благом, с другой же - 
наносит непоправимый вред идее гипертекста. Проблема рескана ещё и в том (я с 
этим столкнулся), что если просто задать боссу команду на рескан - при 
отсутствии у босса этой эхи рескан может вполне и не выполниться, всё зависит -
я так понимаю - от того, как настроена станция у босса.

Вот если бы ввести стандарт не только на FGHI URLы, но и улучшить "пакетную 
передачу данных", то есть что-то вроде передаваемых к аплинку "SQL-запросов" на
сообщения, в единои формате - если аплинк не может выполнить этот запрос, он 
передаёт его своему аплинку, а при получении результата возвращает резульат 
своему даунлинку и кеширует у себя (если так настроено) результаты на случай 
повторных запросов. Соответственно каждый даунлинк при инициации связи передаёт
аплинку набор запросов в виде текстового файла, например:

GET * FROM RU.FTN.DEVELOP TO [адрес получателя:адрес получателя:...] - взять 
все сообщения из эхоконференции, даже если таковые уже есть в локальной базе

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

GET NEW FROM RU.FTN.DEVELOP TO [список адресов] - взять все "новые" сообщения 
из эхоконференции (аплинк "знает", какие сообщения нужно пересылать своим 
даунлинкам) - если у аплинка отсутствуют "накопившиеся" сообщения (даунлинк не 
подписан на эху), то команда аналогична GET * FROM

GET [msgid] TO [список адресов] - взять конкретное сообщение

и далее в том же духе, основная мысль - SQL-подобный язык двунаправленной 
передачи сообщений в пакетном режиме, с возможностью перенаправления запросов 
по своим линкам в случае невозможности выполнения запроса на конкретном узле. 
Для ответов соответственно:

MESSAGE [msgid] TO [адрес получателя:адрес получателя:...] LINES [количество 
строк]
...

- ответ от аплинка даунлинку с текстом сообщения, в поле "адрес" указывается 
вся цепочка, по которой шёл запрос; если получатель не является конечным 
адресатом - пересылает далее по цепочке, "укорачивая" список адресатов.

возможно, имеет смысл сделать и другие информационные команды, например:

GET AREALIST TO [список адресов] - получить список доступных эхоконференций

GET LOCAL AREALIST - получить список эхоконференций, присутствующих на 
непосредственном аплинке

...

Передача сообщений таким образом:

POST [msgid] TO [area list] FROM [adress list] LINES [кол-во линий]

возникает, разумеется, проблема с когерентностью msgid - то есть с тем, чтобы 
на всём пространстве Fidonet msgid не повторялись (так как следует иметь 
однозначную ссылку на сообщение - иначе идея гиперссылок не имеет смысла)

это решается очень просто - всякое msgid должно быть составным

msgid = adress@local msgid

то есть адрес автора сообщения и уникальный (для этого узла/поинта) номер 
сообщения, который не должен повторяться внутри базы этого поинта

...

переход к пакетному SQL-подобному стандартизованному режиму передачи данных 
позволит "отвязаться" от конкретной реализации протокола, возможно - упростит 
"сращивание" некоторых Интернет-форумов с ФИДО.

...

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

...

Далее - я так думаю, что имеет смысл ввести понятие "формата сообщения", 
который должен быть указан в заголовке запроса и ответа. Там могут быть указаны
такие флаги, как:

UTF8 - сообщение в кодировке Unicode (UTF-8)
KOI8 - сообщение в кодировке KOI-8
TEXT - сообщение в обычном текстовом формате без поддержки гипертекста
HTML - сообщение с поддержкой гипертекста (думаю, не стоит изобретать 
велосипед, стандартного HTML будет достаточно - никто не мешает ввести 
требование на разумное использование возможностей гипертекстовой разметки, не 
приводящей к значительной "перегрузке" каналов передачи)

Таким образом, даунлинк запрашивает данные в каком-то *конкретном* формате 
через SQL-подобный язык запросов, и получает сообщения в нём же - то есть если 
я *не хочу* получать HTML-форматированные сообщения (я дорожу своим трафиком и 
вообще сижу на модеме), то я их и не получу - ответственным за конвертацию в 
тот или иной формат является ПО аплинка. Если же ПО аплинка не желает 
поддерживать "тяжёлые" сообщения вроде HTML, то оно может отвечат на запросы 
HTML всё равно сообщениями в формате TEXT.

...

Изображения же хранить в эхоконференциях в виде обычных сообщений (со своим 
msgid), помеченными флагом формата JPEG, GIF и так далее

при запросе на сообщения с указанием формата делать так:

GET NEW FROM [area list] TO [adress list] FORMAT [format list]

например

GET NEW FROM "RU.FTN.DEVELOP, RU.FIDONET.TODAY" TO "2:5030/1104, 
2:5030/1104.666" FORMAT "UTF8, HTML, JPEG, GIF"

- получить от аплинка все сообщения в гипертекстовом формате с поддержкой 
Unicode, а также загрузить все имеющиеся в эхе картинки.

В гипертекстовом же теле сообщения можно ссылаться на него так:

 - то есть по msgid

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

...

точно так же можно делать SQL-подобные запросы аплинку и по времени, и по 
авторству, и по (чем чёрт не шутит!) "тегам" сообщения

...

ввести понятие mixed-эхоконференций, то есть эхоконференций, в которые попадают
сообщения из нескольких эх (точнее это - "логическое обьединение", на ПО 
аплинка может быть настроено так, что логически запросы на mixed-эху 
выполняются сбором сообщений с нескольких, возможно фильтрованных эх - так, 
можно создать mixed-эху MITHGOL, узел будет передавать все сообщения 
пользователя "Сергей Соколов" во всех доступных ему эхах в эту "единую 
конференцию", равно как и ответы этому пользователю)

Hапример, можно иметь иерархию

RU.GAME - всё об играх, в которую попадают сообщения как предназначенные только
для ру.геймов, так и сообщения из эх "менее глобального уровня", например

RU.GAME.STRATEGY - является "частью" эхи RU.GAME

RU.GAME.STRATEGY.HEROES - является "частью" эхи RU.GAME.STRATEGY (и, 
соответственно, эхи RU.GAME)

...

можно организовать физическое Read-only в случае нарушений на уровне бонных 
хабов, которые будут на все запросы от конкретного узла/поинта (внесённого в 
список "награждённых" на узле хаба) таким образом:

запрос:

POST ...

и ответ

POST [msgid] FROM [adress list] FAIL [error code]

- то есть иметь кроме всего прочего и передаваемый от лика к линку "код 
результата", удачный постинг тоже следует помечать в ответе как

POST [msgid] FROM [adress list] OK

...


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

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

------------------
Hо мне кажется, что про это уже писали? Я тут спутанно пишу, может быть немного
наивно (я в ФИДО не так уж и давно, тем более я - поинт, а не нода - поэтому 
многое могу и не знать из "технических подробностей") - но как программист 
молчать не могу ;)

В общем, у меня есть желание участвовать в диалоге :)

Eugeny

--- GoldED+/W32 1.1.5-041013 (New Point Express)
 * Origin: none (2:5030/1104.666)