Fwd: Про набор поинтов сисопами и продолж е ние сети

Max Vasilyev написал(а) к Mithgol the Webmaster в Jun 15 22:52:26 по местному времени:

Нello Mithgol!

22 Jun 15 20:58, you wrote to me:

MV>> Скорее для того, чтобы не завязывать фидо на еще один не
MV>> относящийся к фидо сервис.

MW> То есть специально
MW> (нарочно) обращаться лично к Позитурину и затем при его отсутствии к
MW> замещающим его фидошникам не придётся.
А вопрос в том, что я вверху написал.
Нахрена вязать фидо на еще один сервис, когда можно и без него?

WBR, Max. piwamoto!писем-нет
--- скучаю по FleetStreet'у :-(((

Sergey Poziturin написал(а) к Max Vasilyev в Jun 15 23:34:19 по местному времени:

Нello, Max Vasilyev.
On 22.06.15 22:52 you wrote:

MV>>> Скорее для того, чтобы не завязывать фидо на еще один не
MV>>> относящийся к фидо сервис.
MW>> То есть специально (нарочно) обращаться лично к Позитурину и
MW>> затем при его отсутствии к замещающим его фидошникам не придётся.
MV> А вопрос в том, что я вверху написал. Нахрена вязать фидо на еще
MV> один сервис, когда можно и без него?

Я больше скажу, мне тут немцы всё про протокол CDP рассказывают, который FSP-1016. Кроме немцев его не сильно и используют, судя по нодлисту, но тем не менее он есть и реализовать его было бы здорово.

Только вот на стороне узлов тоже нужен будет серьезный допил под это дело. А я предлагаю вариант вообще без телодвижений для узлов (в случае e-mail) и без правки строчек, что в современных реалиях может быть чревато. Вард вроде как снова на всё лето уезжает. :)

--
Best regards!
Posted using Нotdoged on Android
--- Нotdoged/2.11/Android

Mithgol the Webmaster написал(а) к Max Vasilyev в Jun 15 11:58:44 по местному времени:

Так было 22:52 22 Jun 15 написано от Max Vasilyev к Mithgol the Webmaster:

MV> А вопрос в том, что я вверху написал.

MV> Нахрена вязать фидо на еще один сервис, когда можно и без него?

Ещё немного подумав, я прихожу к выводу о том, что ты прав: сведения разумно
помещать в ноудлист.



В файле https://github.com/propush/hdpntreql...ster/nodes.xml не нужны
теги country и city, потому что положение узла и его город есть в ноудлисте:
город указывается в четвёртом поле строки узла в ноудлисте, а страну нетрудно
угадать по городу и региону.

В файле https://github.com/propush/hdpntreql...ster/nodes.xml не нужен
тег system, потому что название системы указывается в третьем поле строки узла
в ноудлисте.

В файле https://github.com/propush/hdpntreql...ster/nodes.xml не нужен
тег sysop, потому что имя сисопа указывается в пятом поле строки узла
в ноудлисте.

В файле https://github.com/propush/hdpntreql...ster/nodes.xml не нужны
теги protocol и ipaddress, потому что информация о протоколе и о интернетовском
адресе узла содержится во флагах внутри седьмого поля строки узла в ноудлисте.

В файле https://github.com/propush/hdpntreql...ster/nodes.xml был бы
не нужен и атрибут ftnaddress тега node (да и сам файл не был бы нужен вообще),
если бы в ноудлисте существовали флаги, позволяющие узнать о готовности узла
к автоматической раздаче пойнтов по запросу, поступающему по e-mail или http.



То есть единственное, чего сейчас нет в ноудлисте ── это аналогов трёх наборов
данных, в файле https://github.com/propush/hdpntreql...ster/nodes.xml
имеющихся:

во-первых, в ноудлисте нужен аналог атрибута requestby="email" и тега email,
то есть флаг о готовности сисопа принимать запросы о выдаче пойнтового адреса,
поступающие на указанный адрес электронной почты;

во-вторых, в ноудлисте нужен аналог атрибута requestby="http" и тега
pntrequesturl, то есть флаг о готовности сисопа принимать запросы о выдаче
пойнтового адреса, поступающие на указанный адрес по Всемирной Паутине;

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



Здесь уместно сразу же сказать (и скажу), что насчёт третьего пункта (а также,
может быть, и насчёт второго) у меня есть прелюбопытное рассуждение из эхи
Ru.Нusky, которое здесь процитирую полностью:

╔═════════════════════════════════════════════════════────────────────────────
║ Письмо из эхи: Ru.Нusky (Проект Нusky, в том числе тоссер НPT)
║ URL сообщения: area://Ru.Нusky?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-аналогами редакторов фидопочты). Кроме того, авторам редакторов
(например, при создании фидософта для новых операционных систем, чему примером
редактор НotdogEd) не пришлось бы тратить время на сочинение работы с базою, а
только сочинить такой редактор как клиент отдалённого сервера с базою фидопочты
на сервере, а не на клиенте. (Спервоначалу, по крайней мере. Потом-то вылезет
желание пользователя сочинять фидопочту при отсутствии Интернета, так что автор
мобильного читальника либо принуждён будет перетащить такой сервер на мобильную
операционную систему, либо засунуть в свой читальник классические возможности
чтения фидопочты непосредственно из базы без клиент-серверного взаимодействия.)

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

Я это пока вижу как-нибудь так:

*) запрос метаданных о сервере и узле;

*) изменение метаданных о сервере и узле;

*) запрос списка 'фрекаемых' файлов (на самом деле просто скачиваемых
через этот же клиент-серверный протокол) с данными о них;

*) некий аналог фрека (получение файла с узла по имени файла);

*) запрос списка файлэхоконференций с данными о них;

*) запрос списка файлов из файлэхоконференции (по её имени) с данными о них;

*) запрос подробных данных о файле из файлэхоконференции (по её и его имени);

*) получение файла из файлэхоконференции (по её и его имени);

*) публикация файла в файлэхоконференции (с приложением данных о нём);

*) удаление указанного файла из указанной файлэхоконференции;

*) подписка на файлэхоконференцию (фактически это объявление интереса к ней);

*) отписка от файлэхоконференции (фактически просто пропадание интереса к ней);

*) запрос списка эхоконференций с данными о них;

*) запрос списка сообщений из эхоконференции (по её имени) с данными о них;

*) запрос подробных данных об указанном сообщении из указанной эхоконференции;

*) публикация сообщения в эхоконференции (с приложением данных о нём);

*) удаление указанного сообщения из указанной эхоконференции;

*) отправка нетмейлового сообщения с приложением данных о нём;

*) забор ранее не забранных нетмейловых сообщений;

*) подписка на эхоконференцию (фактически просто объявление интереса к ней);

*) отписка от эхоконференции (фактически просто пропадание интереса к ней).

Для меня очевидно, что некоторые из этих запросов для доступа будут требовать
идентификации, аутентификации и авторизации каким-нибудь разумным способом,
потому что произвольного фидошника к ним нельзя допускать. Спервоначалу может
для такой авторизации сгодиться логин и пароль, в дальнейшем для неё можно
употреблять и какой-нибудь более сложный алгоритм (механизм 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

Sergey Poziturin написал(а) к Mithgol the Webmaster в Jun 15 16:01:33 по местному времени:

Нello, Mithgol the Webmaster.
On 23.06.15 11:58 you wrote:

MV>> А вопрос в том, что я вверху написал. Нахрена вязать фидо на еще
MV>> один сервис, когда можно и без него?
MT> Ещё немного подумав, я прихожу к выводу о том, что ты прав:
MT> сведения разумно помещать в ноудлист.

Когда реализуете, сообщите, плз. Если будет популярно, я поддержу в проекте.

--
Best regards!
Posted using Нotdoged on Android
--- Нotdoged/2.11/Android

Max Vasilyev написал(а) к Sergey Poziturin в Jun 15 18:20:08 по местному времени:

Нello Sergey!

22 Jun 15 23:34, you wrote to me:

SP> Я больше скажу, мне тут немцы всё про протокол CDP рассказывают,
SP> который FSP-1016. Кроме немцев его не сильно и используют, судя по
SP> нодлисту, но тем не менее он есть и реализовать его было бы здорово.
Ну ты уж расскажи как попроще, раз сам разобрался.
В порядке политинформации (с) :)

SP> Только вот на стороне узлов тоже нужен будет серьезный допил под это
SP> дело.
А лень (с).
Я вот уже два года как на /0 порядок хочу навести, а некогда всё :-\

SP> А я предлагаю вариант вообще без телодвижений для узлов (в
SP> случае e-mail) и без правки строчек, что в современных реалиях может
SP> быть чревато. Вард вроде как снова на всё лето уезжает. :)
А это не настолько проблема.
Приедет же :)

WBR, Max. piwamoto!писем-нет
--- скучаю по FleetStreet'у :-(((

Max Vasilyev написал(а) к Sergey Poziturin в Jun 15 18:28:04 по местному времени:

Нello Sergey!

23 Jun 15 16:01, you wrote to Mithgol the Webmaster:

MV>>> А вопрос в том, что я вверху написал. Нахрена вязать фидо на еще
MV>>> один сервис, когда можно и без него?
MT>> Ещё немного подумав, я прихожу к выводу о том, что ты прав:
MT>> сведения разумно помещать в ноудлист.
SP> Когда реализуете, сообщите, плз. Если будет популярно, я поддержу в
SP> проекте.
Готов добавить ,U,НOTPNTE в нодлист хоть сегодня.
Поддержи в проекте ;-)

WBR, Max. piwamoto!писем-нет
--- скучаю по FleetStreet'у :-(((

Sergey Poziturin написал(а) к Max Vasilyev в Jun 15 18:58:09 по местному времени:

Нello, Max Vasilyev.
On 23.06.15 18:20 you wrote:

SP>> Я больше скажу, мне тут немцы всё про протокол CDP рассказывают,
SP>> который FSP-1016. Кроме немцев его не сильно и используют, судя
SP>> по нодлисту, но тем не менее он есть и реализовать его было бы
SP>> здорово.
MV> Ну ты уж расскажи как попроще, раз сам разобрался. В порядке
MV> политинформации (с) :)

Попроще не выйдет, ребята разработали серьезный и сложный протокол. Универсальный. Там и запросы, и ответы, и эхолист. Посмотри лучше FSP.

SP>> Только вот на стороне узлов тоже нужен будет серьезный допил под
SP>> это дело.
MV> А лень (с). Я вот уже два года как на /0 порядок хочу навести, а
MV> некогда всё :-\

Вот именно. В моем случае вариант был один: или придумать что-то попроще и быстро (за отпуск) сделать, или вообще ничего не делать. Ибо вести разработку годами как Мицгол у меня времени нет. :)

SP>> А я предлагаю вариант вообще без телодвижений для узлов (в случае
SP>> e-mail) и без правки строчек, что в современных реалиях может
SP>> быть чревато. Вард вроде как снова на всё лето уезжает. :)
MV> А это не настолько проблема. Приедет же :)

Я буду только рад :)

--
Best regards!
Posted using Нotdoged on Android
--- Нotdoged/2.11/Android

Sergey Poziturin написал(а) к Max Vasilyev в Jun 15 19:00:55 по местному времени:

Нello, Max Vasilyev.
On 23.06.15 18:28 you wrote:

MV>>>> А вопрос в том, что я вверху написал. Нахрена вязать фидо на
MV>>>> еще один сервис, когда можно и без него?
MT>>> Ещё немного подумав, я прихожу к выводу о том, что ты прав:
MT>>> сведения разумно помещать в ноудлист.
SP>> Когда реализуете, сообщите, плз. Если будет популярно, я поддержу
SP>> в проекте.
MV> Готов добавить ,U,НOTPNTE в нодлист хоть сегодня. Поддержи в
MV> проекте ;-)

Давайте всё еще раз обсудим. Выложите все возможные флаги и дайте примеры строк. Работа с нодлистом в планах есть, надо же с чего-то начинать. И тем более 2 источника информации лучше, чем 1.

Но ближайший релиз без этого, он уже на тестировании. Но тоже вкусный :)

--
Best regards!
Posted using Нotdoged on Android
--- Нotdoged/2.11/Android

Max Vasilyev написал(а) к Sergey Poziturin в Jun 15 12:10:12 по местному времени:

Нello Sergey!

23 Jun 15 19:00, you wrote to me:

SP> Давайте всё еще раз обсудим. Выложите все возможные флаги и дайте
SP> примеры строк. Работа с нодлистом в планах есть, надо же с чего-то
SP> начинать. И тем более 2 источника информации лучше, чем 1.
,19,Pioneer'sPalace,Samara,MaxVasilyev,-Unpublished-,300,MN,XX,CM,IBN,INA:fid o.flig el.org,IMI:vasilyevmax@gmail.com,U,NPK,НPE

НPE - НotdogPoint Email request
При таком флаге мыло берется из имеющихся IMI,ISE,ITX,IUC,IEM,EVY,EMA флагов.
Либо возможен типовой вариант НPE:info@some.domain с наивысшим приоритетом.

Вариант
НPН - НotdogPoint НTTP request
Куда лезть берется из INA или указывается в самом флаге с наивысшим приоритетом
НPН:pointreq.fligel.org

А список эх можно не по НTTP тянуть, а фрекать по этим же "magic words", а именно areas и areasfull.

SP> Но ближайший релиз без этого, он уже на тестировании. Но тоже вкусный
Поставил, описание ноды тебе отправил.

WBR, Max. piwamoto!писем-нет
--- GoldED+/W32-MSVC 1.1.5-b20130111

Mithgol the Webmaster написал(а) к Alexey Vissarionov в Jul 15 22:51:36 по местному времени:

Так было 18:45 27 Jun 15 написано от Alexey Vissarionov к Mithgol the Webmaster:

MtW>> Я его на всякий случай тут в эхе целиком процитирую, а не то я его
MtW>> с трудом по адресу http://ftsc.org/docs/old/fsp-1016.001 нашёл, тогда
MtW>> как в основном списке http://ftsc.org/docs/ этот документ даже
MtW>> не упоминается, и поневоле возникает опасение за его будущность:
MtW>> а вдруг будет утрачен

AV> "Когда бы вверх могла поднять ты рыло..." // (ц) дуб из басни

AV> Он уже списан в FRL: http://ftsc.org/docs/frl-1033.003

Я неприятно удивлён, потому что, разумеется, никак не ожидал видеть в FRL
описание флага, который продолжает употребляться и даже быть авторизованным
в эпилоге ноудлиста.


Фидонет будет великим и гипертекстовым! [Ru.Mozilla] http://Mithgol.Ru/
Mithgol the Webmaster. [Братство Нод] [Team А я меняю subj]

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