= Сообщение: 653 из 2735 ==================================== RU.FTN.DEVELOP = От : Mithgol the Webmaster 2:50/88 09 Jun 15 13:41:28 Кому : All 09 Jun 15 13:41:28 Тема : О дальнейшем развитии фидонетовского программного обеспечения FGHI : area://RU.FTN.DEVELOP?msgid=2:50/88+5576d047 = Кодировка сообщения определена как: CP866 ================================== ==============================================================================
Сперва новость о twi2fido, иллюстрирующая саму себя:
╔═════════════════════════════════════════════════════──────────────────────── ║ Цитата из эхи: Ru.Blog.Mithgol (Фидонетовский блог Мицгола-вебмастера) ║ URL сообщения: area://Ru.Blog.Mithgol?msgid=2:50/88+5576bf02 ║ Автор и время: @FidonetRunes, 2:50/88 (09 Jun 15 13:25) ║ Кому написано: All ║ Заглавие темы: Twitter: @FidonetRunes ╚════════════════════════════════════════════════════════════════════─────────
Затем позвольте процитировать недавние мысли о возможном интерфейсе REST-типа для доступа к фидонетовской станции через Всемирную Паутину:
╔═════════════════════════════════════════════════════──────────────────────── ║ Письмо из эхи: 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) ────────────────────────════════╪══╬═╣()╠═╬══╪════════────────────────────────
Ко всем, дочитавшим до этого места, у меня вот какое сообщение: я начал уж, пускай и неспешно, разрабатывать приложение для сервера Express.js, которое будет обеспечивать REST-интерфейс и AJAX-отклик в соответствии с теми мыслями, которые я только что процитировал. Вот это приложение:
В связи с этим у меня есть два вопроса: один мировоззренческий вопрос и ещё один вопрос практический.
Мировоззренческий вопрос вот каков: что думаете об этой идее, будет ли она в случае чего на пользу или не особенно, и так далее.
Практический вопрос вот каков: понятно, что логин и пароль было бы досадно передавать открытым текстом или использовать для них какое-нибудь чрезмерно простое зашифровывание (как в binkd, например), но какой метод для передачи вы сочли бы достаточно безопасным?
Жду откликов ваших.
* изначально написано в эхоконференцию Ru.Fidonet.Today * также было отослано в эхоконференцию Ru.FTN.Develop
Фидонет будет великим и гипертекстовым! [Ru.Mozilla] http://Mithgol.Ru/ Mithgol the Webmaster. [Братство Нод] [Team А я меняю subj]
... {27} Hе занимайтесь любовью на койке в отремонтированном летнем лагере. --- Из неоконченного: ``Курилец'', стихотворение с политическим подтекстом. * Origin: И я, откинув точку прочь мою, себя сисопом ныне признаю (2:50/88)
