Skip to main content

Конференции

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

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

Дата: 21 Jun 2015, 01:29:10
От: Sergey Poziturin <Sergey.Poziturin@p2.f2140.n5020.z2.fidonet.org>
Кому: All
Тема: New release is not far away


Hi everyone!
(warning: very long letter inside! :) )

First of all I'd like to thank all of you for your support. Also thank's
for not letting this echo die. :)

The new release of HotdogEd is upcoming and there is one feature I'm
announcing beforehand in order to make all of the sysops who may find it
useful ready for it.

Right now, while version 2.10.x is in public, the user can make a new
point request from HotdogEd. But he can only request it automatically on
my node 2:5020/2141.

Since 2.11, that will ne available next week (I hope), any sysop can
announce his node to accept new point requests.

Point request can be sent from HotdogEd in 2 ways:

1. Via http POST-request to some server. The request must include 4
mandatory POST variables:
_name - point's first name and second name
_email - point's e-mail
_password - password for everything (session, pkt, etc)
_about - some info about the new point so that the sysop can make up his
mind whether to approve or decline the request.

All fields are mandatory in HotdogEd, so the user can not just skip it
and go on.

The server should respond with 2 lines of text: first line is OK or
ERROR (if the point request was approved or declined respectively ) and
the second line is the new 4D-address assigned to the new point (i.e.
2:234/567.89) or the reason of the decline (i.e. Sorry, you are lame).

In case of OK response, HotdogEd makes all the necessary setup
automatically and the user can enjoy fido starting from this moment, if
there is an automatic approve algorythm on the node side. I myself
prefer 2-way algorythm, where the user sends me a request and I approve
it later. The user receives several e-mails after both stages. But it's
up to you to decide. I know one of my friends approves all requests
automatocally.

2. Via e-mail request. HotdogEd just composes a letter to sysop and
sends it by e-mail after user enters all the data about himself
mentioned above. Of course the sysop should receive this email and
manually setup his node to accept the new point. And he should also
notify the point of his new point address. With this method, hotdoged
makes all the setup for the point, except point address, because at the
moment of the request no one actually knows it. So HotdogEd makes setup
for .999 (i.e. 2:234/567.999). The user should edit the address manually
after receiving a response from the sysop.

As you can see the first method requires some effort from sysop to
implement it. But actually not very much. I think one of the sysops in
Russia is already working on some scripts for HPT and binkd for this and
soon they may become available. And Ivan Agarkov (2:5020/848) already
implemented the full auto-approve algorythm in his latest commit to
jNode repository - his beautiful and much loved tosser and mailer
all-in-one written in pure Java. BTW it's very powerfull and full of
features. And production ready! You can check it here:
https://github.com/kreon/jnode

The second method does not require any work extra efforts except listing
your node as point-request available. You just receive e-mails, reply to
them and make configuration changes manually. As you probably did before.

How to make HotdogEd aware of your node accepting point requests? Very
easy. Me and several other guys are maintaining a simple XML-file on
github, take a look at it:
https://github.com/propush/hdpntreqlist/blob/master/nodes.xml
HotdogEd parses it and that's how it's aware of the nodes that accept
point requests. The file is self-explaining and here is the easiest node
description:
    <node ftnaddress="2:5020/1906" requestby="email">
        <country>Russia</country>
        <city>Moscow</city>
        <system>Damage BBS</system>
        <sysop>Alexander Lobachev</sysop>
        <email>ss_di(dog)mail.ru</email>
        <protocol>binkp</protocol>
        <ipaddress>binkp.nauchi.ru</ipaddress>
    </node>
This section tells hotdoged that node 2:5020/1906 in Moscow, Russia
accepts point requests by e-mail specified. Hotdoged automatically makes
setup for this node for binkp protocol (the only one supported at the
moment) and the ip-address binkp.nauchi.ru. Please fill the <country>
and <city> tags carefully - HotdogEd asks the user to choose his
location and it sorts the node list so that the nearest nodes to him are
on top positions. It also awares the user that despite the fact that
fidonet is a world-wide network, some region-specific echo areas exist.

Here is an example of the node (my node btw) with http-request feature:
    <node ftnaddress="2:5020/2141" requestby="http">
        <country>Russia</country>
        <city>Moscow</city>
        <system>Pushkin's BBS</system>
        <sysop>Sergey Poziturin</sysop>
        <note>Welcome, friends. A lot of echoes. No fileechoes. Добро
пожаловать. Много эх. Файлэх нет.</note>
        <email>offspr@pochta.ru</email>
        <protocol>binkp</protocol>
        <ipaddress>vp.propush.ru:24555</ipaddress>

<pntrequesturl>http://vp.propush.ru/pntreq/request.php</pntrequesturl>
        <areasfull>http://vp.propush.ru/pntreq/areasfull</areasfull>
    </node>
Note the <note> tag here :) This is just a note that will be displayed
on the user's phone if he selects 2:5020/2141 before he submits his
point request.

And the tag <areasfull> is the second feature I'd like you to know about
and to get ready for it. It's optional but if you specify it, it should
be the URL where the full echo list of your node can be downloaded.
Everytime the user goes to subscription management in HotdogEd, he will
be able to use the list of areas available from your node. He will see
area name, description, message count and the latest message time for
every echo. You can download the file example and see it yourself:
http://vp.propush.ru/pntreq/areasfull
On my node it is generated every hour automatically.

The file consists of lines of text, one line for single echo. 4
comma-separated fields:
area name, unixtime of the last message, message count, description.
Example:
==
hotdoged,1433136356,35,Autocreated echoarea
==
(note: unixtime is the number of seconds since epoch).

First field (echo name) is mandatory. The rest are optional and can be
omitted for some reason. Examples:
==
hotdoged,,35,The best android fidonet client on earth
linux,,,The best operation system for geeks
==

If someone is using jNode, I can give you an SQL-script that produces
this beautiful listing for tag <areasfull>.

There is also an alternative tag <areas>. It's the URL pointing to a
simple echo list: one area per line, just area name, no other info. Example:
==
n5020.sysop
ru.linux
hotdoged
==

I have a unix shell command for HPT that generates a list of areas for
<areas> tag. If you need it let me know (or ask Alexey Vissarionov,
2:5020/545, he is the author).

In the list of nodes, where the user makes a choice which of the nodes
to prefer, nodes implementing http-requests are higher than those
preferring requests by e-mail. Nodes providing echo list are higher than
the others. Nodes located in the user's country and the city are the
highest ones.

Well, I hope you are not very bored reading all this sh.t. :) These are
not the only features planned for the next release. Stay tuned.

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


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

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