= Сообщение: 1123 из 5336 ========================================= RU.HUSKY = От : Mithgol the Webmaster 2:50/88 27 May 15 16:33:04 Кому : Pavel Gulchouck 27 May 15 16:33:04 Тема : Клиент-серверный протокол доступа к почтовой базе FGHI : area://RU.HUSKY?msgid=2:50/88+5565c79e На : area://RU.HUSKY?msgid=2:463/68+55620d06 = Кодировка сообщения определена как: CP866 ================================== ============================================================================== Так было 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)
