[Cluster-tech] Client protocol for Spider

[Mike Clarke]

Hi list,

I'm in the process of writing a suite of radio-related utilities aimed
primarily at command-line use on GNU/Linux.

This first part of this suite is an ncurses cluster client, which I've
started work on.

Having played with my local cluster node and had a look at the Spider
source, it seems there are a couple of options for a client program
wishing to talk to the cluster:

a) screen-scrape; or,
b) use the PC protocol.

Neither of these options seems ideal.  Screen-scraping an interface
designed primarily with a human user in mind is never fun, and always
fragile.  Equally, from what I understand of the PC protocol, it's designed
mainly for cluster-to-cluster communication, and would need extending to
support concepts such as registration.

I'd be very interested to hear if I've missed anything above; and to
hear from any other client authors on the list about how they interface
with a cluster in a reliable fashion.

An alternative I have been playing around with is adding a special
"client mode" to Spider (yes, I know there is other cluster software in
use as well).

This would be an extension of the VE7CC idea, and would allow a client
to connect to a cluster using an interface designed to be parsed by a
program, rather than a human.

Switching would happen _before_ login, either by sending a special magic
string at the login prompt, or by connecting to a separate port -- I
currently have proof-of-concept code that works by accepting a magic
string at the login prompt and then reblessing the ExtMsg instance into
a subclass of itself which can override methods as required.

The advantage of switching before login is that the cluster can then
return easier-to-parse login results -- for example, a session might
start like:

548 clarkema at swiss:~> telnet localhost 8000
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
login: GALOSHMODE
GALOSHLOGIN: M0PRL
200 LOGIN SUCCESSFUL
READY>

or

201 http://www.gb7mbc.net/

where 201 might indicate "Login successful, but registration
required for full access.  See $URL for full details"  This kind of
response makes it easier to present a useful interface to the end user,
and stop them posting spots into a black hole.

Does this kind of protocol already exist as an option that I've missed?
If not, is it the kind of thing others would be interested in?  If
there is interest, I'm willing to contribute patches along these lines.

Thanks,

-- 
Mike, M0PRL