IcculusNews protocol definition...

[Ryan C. Gordon]

Colin's starting to put together protocol docs for the daemon (initial
work is in CVS...protocol.txt).

A few comments from me, after seeing another's interpretation of what's
going on in my mind based on the daemon source:

Just to be clear, the server responses are nonsense text that shouldn't be
parsed. They are there for debugging over telnet and passing on to humans
when something goes wrong. A robot that is interacting with the daemon
should really only be looking for a '+' or '-' and disregard the rest to
end of line in most cases, since these messages can change at any time
(and/or be localized, extended, made more rude and surly, etc.).

There are exceptions:

1) The initial connection: "IcculusNews daemon <version>" should not
change (or rather, we should agree upon a standard that won't change).
Since this tells the robot that the program on the other side of the
socket really _is_ an IcculusNews daemon, and whether it has a compatible
protocol version. Probably better done as:

   + IcculusNews daemon x.x.x str\012

where 'x.x.x' is the protocol version, and "str" is some human-readable
identifier of the daemon's version (in case someone wants to write their
own implementation of the daemon (har)).

2) "+ You have x bytes. Go hose." ... as we talked about before, this
needs to change. Probably better done as:

   + x\012

I'll find somewhere else to wedge in the term "go hose".  :)

3) Successful response to AUTH is constant. Reasons for failing responses
to AUTH are meant to be human-readable, and intentionally vague (if the
username/password isn't correct, it won't tell you which one failed, or
whether the account even exists). I've debated taking out the "This
account has been disabled", but I don't want locked-out users to spam the
daemon thinking their password is fucked up. Like I said, human-readable.

4) MSG_USAGE isn't constant, either...at least, I think there's some
commands that don't implement this but should. I dunno.

--ryan.