= Сообщение: 683 из 2735 ==================================== RU.FTN.DEVELOP = От : Mithgol the Webmaster 2:50/88 23 Jun 15 11:58:44 Кому : Max Vasilyev 23 Jun 15 11:58:44 Тема : Помыслы о том, как поместить в ноудлист данные о раздаче пойнтов FGHI : area://RU.FTN.DEVELOP?msgid=2:50/88+558920b3 На : area://RU.FTN.DEVELOP?msgid=2:5057/77@fidonet+558859bc = Кодировка сообщения определена как: CP866 ================================== Ответ: area://RU.FTN.DEVELOP?msgid=2:5020/2141.3+03f835d7 ============================================================================== Так было 22:52 22 Jun 15 написано от Max Vasilyev к Mithgol the Webmaster:
MV> А вопрос в том, что я вверху написал.
MV> Hахрена вязать фидо на еще один сервис, когда можно и без него?
Ещё немного подумав, я прихожу к выводу о том, что ты прав: сведения разумно помещать в ноудлист.
В файле https://github.com/propush/hdpntreqlist/blob/master/nodes.xml не нужны теги country и city, потому что положение узла и его город есть в ноудлисте: город указывается в четвёртом поле строки узла в ноудлисте, а страну нетрудно угадать по городу и региону.
В файле https://github.com/propush/hdpntreqlist/blob/master/nodes.xml был бы не нужен и атрибут ftnaddress тега node (да и сам файл не был бы нужен вообще), если бы в ноудлисте существовали флаги, позволяющие узнать о готовности узла к автоматической раздаче пойнтов по запросу, поступающему по e-mail или http.
во-первых, в ноудлисте нужен аналог атрибута requestby="email" и тега email, то есть флаг о готовности сисопа принимать запросы о выдаче пойнтового адреса, поступающие на указанный адрес электронной почты;
во-вторых, в ноудлисте нужен аналог атрибута requestby="http" и тега pntrequesturl, то есть флаг о готовности сисопа принимать запросы о выдаче пойнтового адреса, поступающие на указанный адрес по Всемирной Паутине;
в-третьих, в ноудлисте нужны аналоги тега note и areasfull, то есть флаг о возможности запрашивать об узле какую-то дополнительную информацию опять же через веб-интерфейс.
Здесь уместно сразу же сказать (и скажу), что насчёт третьего пункта (а также, может быть, и насчёт второго) у меня есть прелюбопытное рассуждение из эхи Ru.Husky, которое здесь процитирую полностью:
╔═════════════════════════════════════════════════════──────────────────────── ║ Письмо из эхи: Ru.Husky (Проект Husky, в том числе тоссер HPT) ║ URL сообщения: area://Ru.Husky?msgid=2:50/88+5565c79e ║ Автор и время: Mithgol the Webmaster, 2:50/88 (27 May 15 16:33) ║ Кому написано: Pavel Gulchouck ║ Заглавие темы: Клиент-серверный протокол доступа к почтовой базе ╚════════════════════════════════════════════════════════════════════───────── Так было 20:22 24 May 15 написано от Pavel Gulchouck к Vladislav Vetrov:
PG> Ещё лучше это сделать клиент-серверным протоколом: демон предоставляет PG> доступ к msgbase, редактор взаимодействует с базой через этого демона - PG> в этом случае получается гибче и разделение прав доступа, и PG> независимость формата хранения от почтового клиента.
Мне кажется, что это превосходная идея, страдающая разве что от явной проблемы курицы и яйца: поддержку такого клиент-серверного протокола не будут добавлять в редакторы фидопочты до тех пор, пока не появится серверная часть, а серверную часть никто не станет сочинять до тех пор, пока не появится для неё поддержка в редакторах фидопочты.
Проблема курицы и яйца вообще является, как я понимаю, пагубною для Фидонета на стыках между мейлером и тоссером или между тоссером и редактором почты: она консервирует в первом случае формат пакета, а во втором случае форматы баз (JAM и Squish).
Интересно, что независимость формата хранения от почтового клиента не снимает проблему курицы и яйца, а просто перемещает формат хранения на другой стык, находящийся между эхопроцессором и сервером такого протокола. Это, конечно, если эхопроцессор не научить тому же клиент-серверному протоколу. Вообще же через тот же клиент-серверный протокол могли бы пообщаться с базою и файловый эхопроцессор (сиречь тикер), и даже мейлер.
Тем не менее клиент-серверный протокол может быть весьма полезен, особенно если его сделать понятным для браузеров Интернета (например, в виде AJAX-запросов), после чего такой протокол мог бы употребляться не только в редакторах фидопочты в строгом смысле слова, но также и на WebBBS (то есть, грубо говоря, на сайтах, являющихся web-аналогами редакторов фидопочты). Кроме того, авторам редакторов (например, при создании фидософта для новых операционных систем, чему примером редактор HotdogEd) не пришлось бы тратить время на сочинение работы с базою, а только сочинить такой редактор как клиент отдалённого сервера с базою фидопочты на сервере, а не на клиенте. (Спервоначалу, по крайней мере. Потом-то вылезет желание пользователя сочинять фидопочту при отсутствии Интернета, так что автор мобильного читальника либо принуждён будет перетащить такой сервер на мобильную операционную систему, либо засунуть в свой читальник классические возможности чтения фидопочты непосредственно из базы без клиент-серверного взаимодействия.)
Видя такую пользу, предлагаю обсудить вопрос о том, какие возможности окажутся необходимыми для подобного протокола (или, иными словами, каким должно быть множество таких запросов, которые клиент будет слать на сервер).
Я это пока вижу как-нибудь так:
*) запрос метаданных о сервере и узле;
*) изменение метаданных о сервере и узле;
*) запрос списка 'фрекаемых' файлов (на самом деле просто скачиваемых через этот же клиент-серверный протокол) с данными о них;
*) некий аналог фрека (получение файла с узла по имени файла);
*) запрос списка файлэхоконференций с данными о них;
*) запрос списка файлов из файлэхоконференции (по её имени) с данными о них;
*) запрос подробных данных о файле из файлэхоконференции (по её и его имени);
*) получение файла из файлэхоконференции (по её и его имени);
*) публикация файла в файлэхоконференции (с приложением данных о нём);
*) удаление указанного файла из указанной файлэхоконференции;
*) подписка на файлэхоконференцию (фактически это объявление интереса к ней);
*) отписка от файлэхоконференции (фактически просто пропадание интереса к ней);
*) запрос списка эхоконференций с данными о них;
*) запрос списка сообщений из эхоконференции (по её имени) с данными о них;
*) запрос подробных данных об указанном сообщении из указанной эхоконференции;
*) публикация сообщения в эхоконференции (с приложением данных о нём);
*) удаление указанного сообщения из указанной эхоконференции;
*) отправка нетмейлового сообщения с приложением данных о нём;
*) забор ранее не забранных нетмейловых сообщений;
*) подписка на эхоконференцию (фактически просто объявление интереса к ней);
*) отписка от эхоконференции (фактически просто пропадание интереса к ней).
Для меня очевидно, что некоторые из этих запросов для доступа будут требовать идентификации, аутентификации и авторизации каким-нибудь разумным способом, потому что произвольного фидошника к ним нельзя допускать. Спервоначалу может для такой авторизации сгодиться логин и пароль, в дальнейшем для неё можно употреблять и какой-нибудь более сложный алгоритм (механизм OAuth, например). Даже и логин да пароль следовало бы передавать не простым текстом, а как-нибудь посложнее исхитриться (ну, например, использовать дайджестную аутентификацию согласно RFC 2617 или безопасный дистанционный пароль SRP согласно RFC 2945).
Для меня очевидно, что выполнение некоторых из этих запросов окажется заметно продолжительным для сервера, так что их суммарное количество и объём надо будет ограничивать для предотвращения отказа в обслуживании; в известной же мере это касается и объёма отдельных запросов.
В частности, некоторые списки (прежде всего список сообщений в эхоконференции) могут содержать тысячи и десятки тысяч элементов, так что на первый запрос их надо предусмотреть возможность частичного ответа, а также предусмотреть запросы со смыслом 'дальше' / 'ещё'.
Для меня очевидно, что такой клиент-серверный протокол сможет заменить собою фрек-процессор, сможет заменить собою ареафикс и даже быть лучше ареафикса (так как обеспечит возможность рескана без подписки и в том числе выборочного рескана). Факт подписки или отписки потеряет своё первоначальное значение и будет носить чисто информационный характер, позволяя делать, например, такие умозаключения:
── Вот эта эха никому из подписчиков не нужна.
── Вот этой эхи нет на узле, а её просят.
Есть ли у кого-нибудь дополнительные идеи, поправки, комментарии, вопросы?
Фидонет будет великим и гипертекстовым! [Ru.Mozilla] http://Mithgol.Ru/ Mithgol the Webmaster. [Братство Нод] [Team А я меняю subj]
... Жираф идёт пить не один, а в компании с другими животными. (перлы ШБО) ■■■ Наш Фидонет читают и дети! Улучшайте их языкознание: ставьте точки над "ё" √ Origin: Но я лишь голос вопиющего в пустыне ── ``RTFM, LMD!!!'' (2:50/88) ────────────────────────════════╪══╬═╣()╠═╬══╪════════────────────────────────
Суть той идеи сводится к тому, что у узла должен быть некоторый более или менее унифицированный веб-интерфейс (причём не интерфейс пользователя, а скорее API для программного обеспечения). Удобнее всего был бы RESTful API, отдающий JSON (потому что это для WebBBS с их джаваскриптом и AJAX удобно, а прочему софту более или менее пофигу).
В таком случае запрос списка эхоконференций ── это запрос к такому API, и запрос метаданных об узле ── это опять же запрос к такому API, и запрос пойнтового адреса ── это опять же запрос к такому API.
В ноудлисте же вместо ряда отдельных флагов (вон там брать правила эх, вон там брать описание узла, вон там брать пойнта) достаточно тогда один раз указать корневой каталог такого API, через который можно подавать все такие запросы.
Место в ноудлисте тогда экономится (что важно; я слышал, что размер строчек в ноудлисте весьма ограничен, так что в раздельном виде все необходимые адреса могут ведь в одну строчку и не поместиться).
По адресу https://github.com/Mithgol/node-fidonet-nodelist я стал уж понемногу набрасывать свои представления о том, как может выглядеть открытый исходный код реализации такого веб-интерфейса.
Фидонет будет великим и гипертекстовым! [Ru.Mozilla] http://Mithgol.Ru/ Mithgol the Webmaster. [Братство Нод] [Team А я меняю subj]
... Великих мужей рождают не матери, а Плутархи. (Станислав Ежи Лец) --- Эшелону: отражение Spoke Talent Trump FX FXR IMF POCSAG rusers * Origin: Геленджик лежит на юге Раши, где в лесу рыдают хигураши (2:50/88)
