Skip to main content

Конференции

Просмотр конференции fido7.r50.sysop:

Предыдущее Следующее

Дата: 15 Jun 2015, 14:07:35
От: Sergey Poziturin <Sergey.Poziturin@p2.f2140.n5020.z2.fidonet.org>
Кому: All
Тема: Про набор поинтов сисопами и продолжени е сети


Привет, коллеги.

Заранее извиняюсь, если эта конференция не совсем подходит для подобной
тематики, но здесь я наверное найду максимальную аудиторию, да и тема
острая.

Как вы возможно знаете, я являюсь разработчиком бесплатного фидошного
"клиента" для устройств под управлением Android под названием HotdogEd.
Если не знаете, то подробности и скриншоты тут:
http://vp.propush.ru/index.php?q=node/149
Но тема не совсем об этом.

Полтора года назад в хотдоге была реализована возможность запрашивать
поинта на моём узле 2:5020/2141 прямо в GUI программы, шёл запрос на
сервер, откуда давался ответ (ОК или нет) и сразу же номер нового поинта
автоматом прописывался в программу. Далее мне приходило уведомление о
запросе, я подтверждал или отвергал его, юзер получал соответствующее
письмо и начинал пользоваться софтом. Этой возможностью с момента
запуска воспользовалось более 400 человек! Далеко не все из них являются
активными поинтами, и далеко не все смогли получить поинта благодаря
моей криворукости и катастрофическому отсутствию времени.

Но это лирика, а суть в следующем. Неправильно, что в хотдоге такая
полезная фича завязана на один узел. В новой версии хотдога будет
возможность сделать запрос на получение поинтового адреса из программы
на любом узле, который захочет принять в этом участие.

Как это работает:

1. При выборе в хотдоге пункта "Request point" у юзера появляется окно с
вводом информации о себе и с выбором желаемого узла. Список узлов
скачивается тут же через интернет с сайте github.com, представляет он
собой XML с описанием параметров узла и возможностей, которые
предоставляются пользователю. Вот полный адрес файла, там же можете
посмотреть, как что устроено. Данные в настоящий момент тестовые:
https://github.com/propush/hdpntreqlist/blob/master/nodes.xml

2. Юзер выбирает желаемый узел, заполняет ФИО, пароль, мыло, несколько
слов о себе и нажимает кнопку "Submit", после чего запрос улетает на
узел. Каким образом улетает запрос, зависит от указанного в XML, это
может быть как http[s]-запрос, так и обычный e-mail на указанный адрес.
 - В случае http, в POST-параметрах передаются данные пользователя, а в
ответ сервер должен сообщить адрес присвоенного поинта. Этот адрес
записывается в настройки хотдога.
 - В случае e-mail, сисопу уходит письмо. Поскольку хотдог поинтового
адреса не знает, то он делает настройки на .999 и предупреждает
пользователя, что он после получения ответа от сисопа должен изменить
номер самостоятельно. Все остальные параметры уже введены.

Таким образом мы даём юзеру возможность легко и без проблем с настройкой
выполнить подключение.

Чтобы принять участие в этом аттракционе, необходимо мне прислать
описание вашего узла в следующем формате:

Вариант с запросом по http:
    <node ftnaddress="2:5020/9999" requestby="http">
        <country>Russia</country>
        <city>Moscow</city>
        <system>Test node just testing</system>
        <sysop>Ivan Petrov</sysop>
        <email>sysop@fidonet.net</email>
        <protocol>binkp</protocol>
        <ipaddress>your.fqdn:24554</ipaddress>

<pntrequesturl>http://vp.propush.ru/testpntreq/request.php</pntrequesturl>
    </node>
Порт можно опустить, если он стандартный (для binkd 24554).

Вариант с запросом по e-mail:
    <node ftnaddress="2:5020/9998" requestby="email">
        <country>Some country</country>
        <city>Burgergrad</city>
        <system>Burger lovers station</system>
        <sysop>Vano Sysopov</sysop>
        <email>sysop9998@yandex.ru</email>
        <protocol>binkp</protocol>
        <ipaddress>somehost.ru</ipaddress>
    </node>

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

Дополнительная, но очень важная фича - опциональные тэги <areas> или
<areasfull>. Это указание, откуда хотдог может скачать списки эх в
кратком (areas) или полном (areasfull) формате.
Пример:
    <node ftnaddress="2:5020/9999" requestby="http">
        <country>Russia</country>
        <city>Moscow</city>
        <system>Test node just testing</system>
        <sysop>Ivan Petrov</sysop>
        <email>sysop@fidonet.net</email>
        <protocol>binkp</protocol>
        <ipaddress>vp.propush.ru:24555</ipaddress>

<pntrequesturl>http://vp.propush.ru/testpntreq/request.php</pntrequesturl>
        <areas>http://vp.propush.ru/testpntreq/areas</areas>
    </node>

Краткий формат - просто название эхи, по одному на строку (\n или \r\n),
например:
==
n5020.sysop
ru.linux
==

Полный формат - в каждом файле следующая информация об эхе через запятую:
название,unixtime последнего сообщения,количество сообщений[,описание эхи]
Пример:
==
pushkin.local,1434352755,19698,Pushkin's local echo
su.kitchen,1434352123,150,Kitchen
zzz.abc,1434352755,89,
test.echo,1434352755,112
==

Поскольку я пытаюсь сделать всё это как можно более
клиентоориентировнным в рамках моего отсутствующего эстетического
восприятия и неумения делать GUI, то при выборе узла для подачи заявки в
списке будет выполняться сортировка по следующему алгоритму: выше будут
те узлы, которые предоставляют больший сервис. Если узлы предоставляют
одинаковый сервис, то выше будет тот, у которого номер меньше
(сравниваем числа).

Под сервисом я подразумеваю вот что: сервис подачи заявки через http
выше, чем через e-mail (потому что меньше ручного труда юзеру). Узел,
предоставляющий полный формат эх, будет выше, чем тот, который
предоставляет краткий. И оба будут выше того, который вообще такого
списка не даёт. Если узел предоставляет список эх, но запрос поинта идёт
по e-mail, то он будет выше узла, который не даёт списка эх, но запрос
поинта идёт по http. Потому что поинта юзер попросит один раз, а к
списку эх будет возвращаться постоянно.

На скриншоте видно, как в первом приближении выглядит список с выбором узла:
https://www.dropbox.com/s/ufid4gdn1sh8pby/device-2015-06-15-103824.png

Если кому-то интересно, как для http двухпроходная схема
(запрос-подтверждение) реализована на /2141, могу предоставить мои
кривые скрипты на php (у меня на узле jnode). Ну а кто не хочет городить
веб-сервер, может просто поучаствовать в раздаче поинтов по e-mail. От
вас потребуется быстрая реакция и стабильная работа узла, дабы не
посрамить :) При http-запросе всё, что нужно знать хотдогу - это 2
строки. В первой OK или ERROR, а во второй - поинтовый адрес, который
присвоен поинту в случае ответа OK. Пример:
==
OK
2:5020/9999.2
==
ну или тут:
http://vp.propush.ru/testpntreq/request.php

В дальнейшем вся эта тема может быть силами любого человека вынесена за
пределы телефона. То есть никто не мешает сделать на собственном сайте,
посвящённом фидо, запрос на поинта. Можно даже сделать универсальный
виджет на столь любимом многими javascript, который можно было бы
встроить на любой сайт вообще. Формат расширяем и дополняем.

Техническое обсуждение, если у кого-то есть вопросы и предложения по
форматам и т.п., логичнее продолжить в ru.ftn.develop (это письмо туда
также уйдёт).

По срокам: я планирую запустить всё это в промышленную эксплуатацию в
течение 1-2 недель. Все, кто к этому времени пришлёт описание и настроит
узлы, получат некоторое количество новых поинтов. Мой узел в списке тоже
будет. Вся часть с запросами уже реализована, сейчас работаю над
списками конференций. В релизе будет всё и сразу.

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

-- 
[ pushkin_kukushkin@jabber.ru ] [2:5020/2140]
http://vp.propush.ru


Предыдущее Следующее

К списку сообщений
К списку конференций