[Cluster-tech] Client protocol for Spider

[Mike Clarke]

On Tue, Jan 13, 2009 at 5:44 PM, Simon (HB9DRV) <simon at hb9drv.ch> wrote:

> Hi,
>
> You can get all spots in a nicely delimited format by issuing a 'special'
> command set/ve7cc which changes the format of received data.
>
> This is what I'm doing with a new Windows-based logbook and get all the data
> I want.
>
> Look at VE7CC's Windows program - he uses the ve7cc option. I was thinking
> about wring a client which connects into the DX Spider network but there's
> really no need.

Hi Simon,

Thanks for the reply.

I'm aware of the VE7CC mode, and that's fine for the spots (although it
seems to have some lurking gotchas!)  My main issue is with other
areas of the interface.

Before I go any further, it's worth pointing out that none of this is aimed
at Spider particularly -- I'm aware that it inherited its user-interface from
software designed only to interface with human users.

With that out of the way...

1.  How do I know what a prompt looks like?  Yes, I can send random input
to the cluster, take the last line of its reply, rinse and repeat
until I've had the
same result twice in a row[1], and then consider that to be the prompt.  That
would probably work in most cases, but is undeniably hacky

2. When logging in, how do I know if a user has full access, or is required to
register to perform certain actions?  I can't currently see any way around this
one.  You could, perhaps, detect the MOTD, display it, and then blame the
user, but that presumes:

a) the MOTD mentions a requirement for registration somewhere
b) the user actually reads it
c) the user _can_ read it -- if the MOTD isn't written in their native language,
    the user might have problems reading a block of prose.

On the other hand, if the cluster responds with a success code of some kind
following login, the client knows exactly what the user's status is, and can
display a localized help message if the user needs to register.  Yes, that
doesn't _entirely_ deal with the language issue, but at least they have an
idea what the problem is and have been aimed roughly in the right direction.

3. A more generalized form of 2 is the cluster's response to any other given
command.  As far as I can see, there is no standard way of telling whether a
command worked or not.  Do I look for "success" or some similar search?  If
so, what if the user has set his interface language to German?  I could detect
the interface language on login, perhaps, and then set it to English, then
revert on logout.  However, if the connection is uncleanly closed then the
users's language settings will be left at English -- rather impolite.

Again, this could be addressed by a "client" mode, where the prompt is well
known,  and there are specific codes for success, failure, and
sub-types of each,
for various user commands.  These are easy for the client to parse, and easily
localized on the client side.

Basically, this is just a proposal for extending the concepts behind VE7CC mode
a little more, to make parsing output from the cluster easy; easy
parsing is robust,
reliable, and can be achieved with simpler, shorter code.  Simpler,
shorter code is
good, because it encourages others to get involved and means I don't have to
write the whole thing myself ;)  It also provides the client with
richer information,
which it can use to present the user with clearer indications of status.

If I've missed something above -- sorry!  I'm not terribly familiar
with clusters yet,
so am more than willing to be pointed in the right direction!

[1] To avoid the case where the cluster sends you an unsolicited spot
immediately after the prompt, and you end thinking that's the prompt
you need to look for in future...


-- 
Mike, M0PRL