= Сообщение: 2635 из 3030 =================================== GANJANET.LOCAL = От : Mithgol the Webmaster 2:5063/88 15 Aug 08 23:16:32 Кому : Konstantin Kuzov 15 Aug 08 23:16:32 Тема : FGHI ICQBot && FGHI FReqBot FGHI : area://GANJANET.LOCAL?msgid=2:5063/88+48a5d80e На : area://GANJANET.LOCAL?msgid=2:5019/40.1+48967dc4 = Кодировка сообщения определена как: CP866 ================================== Ответ: area://GANJANET.LOCAL?msgid=2:5019/40.1+48a75ef0 ============================================================================== Так было 07:55 04 Aug 08 написано от Konstantin Kuzov к All:
KK> Если в вашем профиле на /400 прописан icq-номер с которого пришел запрос, KK> то права на доступ к конференциям равны вашей учетке, иначе правам KK> анонимуса.
Это очень полезная штука, всей глубины полезности которой ты не ведаешь, и я не ведаю также. Предлагаю её существование осветить более широко, и тем познать глубину востребованности её. Что ты об этом думаешь?
KK> Поддерживает очередь, к примеру, в запросном req-файле может быть: KK> area://R50.SYSOP?msgid=2:6001/9+48960e52 KK> area://GANJANET.LOCAL?msgid=2:5019/40.1+452fe95d&kludge=1 KK> В результате придет pkt-шка, содержащая netmail-сообщения с письмами. KK> Прямой постинг в эхи делать не стал, ибо во-первых должен быть разрешен KK> автокрейт, а во-вторых такие письма будут разлетаться всем линкам KK> запрашивающего.
KK> Примечание: Hетмейл обоими роботами не поддерживается.
Этот инструмент выглядит до крайности занимательно, но несколько противоречит моему представлению о том, что такое фрек (файловый запрос). С одной стороны, это действительно файловый запрос в том смысле, что приходит ведь файл (сиречь PKTшка). С другой стороны, кажется заметно неадекватным задаче, когда ко фреку отправляется такой запрос, который более приличествовало бы отправить, скажем, к ареафиксу. Ты же понимаешь не хуже меня (а скорее и лучше меня, ты ж ведь это запрограммировал): всё это действие ── это, фактически, особая форма рескана; её приличествует исполнять ареафиксу, или, во всяком случае, некоему особому почтовому боту. Понимаешь, что я имею в виду? С третьей стороны, я превосходно понимаю смысл, который ты вкладывал в этого фрек-бота ── он позволяет мгновенно получить желаемое (как обычно случается при фреке), а не дожидаться очередного (последующего) сеанса связи (как обычно случается при нетмейловом запросе). Мне кажется, что противоречие между формой и смыслом здесь можно снять посредством некоторого механизма, который я один или два раза упоминал в Ru.FTN.Develop, и который я дополнительно обдумывал буквально на этой же вот неделе, размышляя о необходимости расширения стандарта WaZOO-фреков (FTS-0006.002). Плоды моих размышлений займут своё место в разделе 7.5.6 моего черновика стандарта FGHI URL; сейчас я поделюсь с тобою неокочательной версией этого раздела:
7.5.6. URL-based extension for WaZOO file requests -+------------------------------------------------
According to FTS-0006.002, a WaZOO file request is based on a request file (.REQ file), and each line of such a file contains the following elements (space-separated from each other):
*) The filename of a requested file. This element is mandatory.
*) A password to get the requested file. This element is optional and is always preceded by an exclamation mark ("!" character) to distinguish it from the other optional element.
*) The type of update and the time. This element is optional and is always preceded by a plus sign ("+") or a minus sign ("-") to indicate the update type and to distingush this optional element from the other.
If the system which sends the request is capable of creating FGHI URLs, it MAY extend the line with yet another optional element:
*) The "freq://" URL of the file. This element is always preceded by an opening square bracket ("[") and followed by a closing square bracket ("]") to distinguish it from the other optional elements.
Such an URL-based extension for WaZOO file requests has the following advantages:
*) It is backwards-compatible: even if the freq server that processes the request is not aware of FGHI URLs, it still MAY read the filename at the beginning of a line and respond with the desired file.
*) The "freq://" URL MAY contain the "fecho" optional parameter (see section 7.5.5), so a freq server completely subscribed to some file echo MAY provide partial file feeds of it to its clients.
*) The "freq://" URL MAY contain the "ed2k" optional parameter (see section 7.5.3) and the "size" optional parameter (see section 7.5.2), and then a freq server MAY ignore the given filename and becomes capable of finding even a renamed file if that has the desired ed2k hash and size. A freq server MAY also act as a Fidonet interface to the ed2k/Kad file exchange network, getting files from some other ed2k/Kad servents on behalf of some other Fidonet systems. The "aich" optional parameter, if it's present in the URL, assists in both of these possible tasks.
*) The "freq://" URL contains the server address, and thus the response MAY vary accordingly. Virtual servers (virtual points) MAY coexist on the same physical station (like in WWW virtual hosts aka virtual servers coexist on the same Web server, where the HTTP response MAY vary according to the "Host" field of the incoming HTTP/1.1 request).
*) Freq servers MAY also accept URLs containing addresses of other freq servers, and forward such requests to that servers. If an uplink or downlink is known to support the protocol of distributed file requests, proposed in FSC-0071, then the request MAY be forwarding through that link via FSC-0071. If an uplink or downlink is known to support URL-based extension for WaZOO file requests and to accept other servers in URLs, then the request MAY be forwarded through that link in the same manner it was initially received by the forwarding node.
*) Freq servers MAY also accept some URLs that are not based on the "freq://" scheme; by accepting and serving these URLs, such servers MAY act, for example, as file gates that allow other Fidonet stations to request FTP-hosted or HTTP-hosted files by their URLs.
When HTML page is provided by the freq gate, the linked files of that page (such as images, stylesheets, scripts, embedded objects) MAY also be provided, so that the gate will spare its clients the trouble of requesting such files. However, the client MAY already have all these files requested and cached.
Вот как это выглядит в русском переводе:
7.5.6. Расширение на основе URL для файловых запросов WaZOO -+---------------------------------------------------------
Согласно FTS-0006.002, файловый запрос WaZOO основывается на файле запроса (.REQ-файле), и каждая строка такого файла содержит следующие элементы (разделённые пробелами друг от друга):
*) Имя запрошенного файла. Этот элемент обязателен.
*) Пароль на получение запрошенного файла. Этот элемент необязателен и ему всегда предшествует восклицательный знак (символ "!"), чтобы отличить его от другого необязательного элемента.
*) Тип обновления и время. Этот элемент необязателен, и ему всегда предшествует плюс ("+") или минус ("-"), чтобы обозначить тип обновления и отличить этот необязательный элемент от другого.
Если система, которая отсылает запрос, способна создавать URLы FGHI, она МОЖЕТ расширить эту строку ещё одним необязательным элементом:
*) URL "freq://" файла. Этому элементу всегда предшествует открывающая квадратная скобка ("["), а за ним следует закрывающая квадратная скобка ("]"), чтобы отличить его от других необязательных элементов.
Такое расширение на основе URL для файловых запросов WaZOO имеет следующие преимущества:
*) Оно обладает обратной совместимостью: даже если freq-сервер, обрабатывающий запрос, не знает об URLах FGHI, он всё равно МОЖЕТ прочесть имя файла в начале строки и отреагировать желаемым файлом.
*) URL "freq://" МОЖЕТ содержать необязательный параметр "fecho" (см. раздел 7.5.5), стало быть, freq-сервер, полностью подписанный на какую-либо файловую эху, МОЖЕТ обеспечивать частичную подачу её файлового материала своим клиентам.
*) URL "freq://" МОЖЕТ содержать необязательный параметр "ed2k" (см. раздел 7.5.3) и необязательный параметр "size" (см. раздел 7.5.2), и тогда freq-сервер МОЖЕТ игнорировать данное имя файла и становится способным найти даже переименованный файл, если тот имеет желаемый ed2k-хэш и размер. Freq-сервер МОЖЕТ также действовать в качестве фидонетовского интерфейса к файлообменной сети ed2k/Kad, получая файлы от каких-либо других сервентов ed2k/Kad в интересах каких-либо других систем Фидонета. Необязательный параметр "aich", если он присутствует в URLе, содействует в каждой из этих возможных задач.
*) URL "freq://" содержит адрес сервера, и оттого отклик МОЖЕТ меняться соответственным образом. Виртуальные серверы (виртуальные пойнты) МОГУТ сосуществовать на одной физической станции (как в WWW виртуальные хосты aka виртуальные серверы сосуществуют на одном вебсервере, где HTTP-отклик МОЖЕТ меняться соответственно полю "Host" входящего запроса HTTP/1.1).
*) Freq-серверы МОГУТ также принимать URLы, содержащие адреса других freq-серверов, и передавать такие запросы этим серверам. Если известно, что аплинк или даунлинк поддерживает протокол распределённых файловых запросов, предложенный в FSC-0071, тогда запрос может быть передан через этого линка посредством FSC-0071. Если известно, что аплинк или даунлинк поддерживает расширение на основе URL для файловых запросов WaZOO и принимает другие серверы в URLах, то запрос МОЖЕТ быть передан через этого линка таким же образом, каким он изначально был получен передающим узлом.
*) Freq-серверы МОГУТ также принимать некоторые URLы, не основанные на схеме "freq://"; принимая и обслуживая эти URLы, такие серверы МОГУТ действовать, например, в качестве файловых гейтов, позволяющих другим фидонетовским станциям запрашивать файлы, лежащие на FTP или HTTP, по их URLам.
Когда freq-гейт снабжает HTML-страницею, то взаимосвязанными файлами этой страницы (такими, как картинки, стилевые листы, скрипты, внедрённые объекты) он также МОЖЕТ снабжать.
(Последний абзац ещё не полностью дописан и переведён, и после него могут ещё быть дополнительные мысли ── прежде всего, о том, что надо как-то отмечать в ноудлисте флагами те узлы, которые способны воспринимать FGHI URL во фреках, и ещё те узлы, которые не только freq-URLы воспринимают, и ещё те узлы, которые способны передавать freq-запросы по цепочке.)
Теперь давай посмотрим с этой точки зрения на вот этот твой URL:
1) Он даёт пользователю возможность запросить конкретное сообщение из эхи, имеющее msgid 2:5019/40.1024 434ea8e9
2) Он сообщает пользователю о том, что узел 2:5019/400 принимает особого вида файловые запросы, которые содержат URLы area://
3) Он подразумевает какой-то протокол передачи URLа 'area://...' на узел ── например, простое появление этого URLа в очередной строчке .REQ-файла.
Однако, на самом деле, URL не должен всего этого делать, поскольку это идёт сильно во вред универсальности URLа. Если бы URL решал только первую задачу, то имел бы универсальный вид:
и позволял бы браузеру Фидонета (например, NoSFeRaTU's GoldEd+) самостоятельно принять решение о том, откуда брать сообщение, если его нету в локальной базе. Может быть, в силу устройства браузера ── или пользовательских настроек его ── браузеру просто не захочется фрекать сообщение, и он сперва на гейт полезет. Достоинство универсальности URLов именно в этой свободе выбора заключается.
Третью задачу должен решать стандарт ── можно надеяться на то, что я предложил такую схему расширения WaZOO, к которой у тебя не будет особых нареканий. (Хотя, даже если они и будут, и даже если в итоге протокол будет какой-нибудь заметно другой, то всё равно не в каждый URL отдельно его приличествует пихать, но только один раз и в стандарт.)
Вторую задачу можно решать несколькими способами ── и они не взаимоисключающие. Во-первых, можно в ноудлисте пометить узел в качестве принимающего area-URLы во фреках. Во-вторых, можно расширить формат AREAS.BBS (или фидоконфига, или ещё какого-нибудь конфигурационного файла ── .CFG-файла от NoSFeRaTU's GoldEd+, если угодно) таким образом, чтобы там можно было указывать не только типы локальных баз (MSG/Opus, JAM, Squish и т. п.), но и какие-нибудь FGHI-гейты (http://fghi.pp.ru/?%s), FGHI-фреки (freq://2:5019/400). В том числе для этого Фидонету нужен XML-эхолист ── он может одновременно хранить сведения об эхе и о её хранилище, а также URL правил эхи, так что и FGHI-гейты, и FGHI-фреки могли бы уведомлять, какие эхи они раздают, как надо себя в них вести. Ну и в-третьих, пользователь может просто взять URL freq://2:5019/400 и добавить в закладки фидобраузера, пометив в качестве обработчика внешних area-запросов, работающего по умолчанию.
Хочу ещё раз подчеркнуть, что это не взаимоисключающие способы, и в идеале они даже дополняют друг друга. Рассмотрим, например, пошагово такой сценарий:
Нетрудно приметить, что сценарий этот вполне реалистичен.
Все вышеперечисленные аргументы идеологического характера, хотя они и указывают на определённую необходимость пересмотра формата тобою выше приведённого URLа freq://2:5019/400/area://GANJANET.LOCAL?msgid=2:5019/40.1024+434ea8e9 ── всё же являются более второстепенными, менее заметными, чем главный этого URLа недостаток: нельзя просто так скармливать URL фрек-серверу, это FTS-0006.002 противоречило бы. В том числе поэтому я придумал заключать URL в квадратные скобки и ставить не в начале строки ── это более вписывается в рамки WaZOO.
Фидонет будет великим и гипертекстовым! [Ru.Mozilla] http://Mithgol.Ru/ Mithgol the Webmaster. [Братство Нод] [Team А я меняю subj]
... Татьяна копила, копила и всё это вылила на Онегина. (школьное сочинение) --- Эшелону: 3848 Morwenstow Консул Oratory Pine Gap Menwith Mantis DSD BVD * Origin: Тогда советские ── по пояс в снегу ── двинулись вперёд! (2:5063/88)
