eric writes:
> > > http://www.dolda2000.com/~fredrik/doldaconnect/protocol.html
> > This is just my opinion but I give my reasons:
> > Format:
> ======
> CRLF vs CR: I think using a single character (not only CR) as
> command separator is better because it uses less bandwidth but also
> because it is faster to search (only 1 byte to compare instead of
> 2) and commands can be splitted using a simple strchr().

Yeah... I just recently implemented a protocol parser for the UI
controller channel for my new client, and I just couldn't find a
really elegant way of handling CRLFs... I'm pretty much for that as
well. I'll change it in the spec.

> Quoting: That seems good to me but we must define how backslashes are handled > when encountered inside double quote (ignore the \ and discard it or keep it > working as outside double quote). I think backslash should work everywhere in > the same way and more over, this will allow this "somewords\"otherwords".

That was precisely what I was thinking. I thought I had made that
clear enough? I'll look over my wording.

> Semantics:
> ========
> > Roles: DC without this architecture is not DC :)
> > Word sets: I think commands should be case-sensitive (for faster
> comparison) but we should forbid commands having same
> case-independent values (like toto and Toto).

OK, I can agree to that; it has another reason as well. The ISO C spec
doesn't actually have a wcscasecmp function declared. When I checked
it out, wcscasecmp was a GNU extension to glibc. Therefore, that might
actually be a good idea in more than one way. So... uppercase or
lowercase? =)

In that case it'll have to be lowercase - easier to type. I'm sure
everyone agrees. I'll change that too.

> User identification: ok for me.
> > Search criteria: we should also define the maximum number of reply a client > can send.

That might actually be a good idea. However, I see that being part of
the search protocol, not the criteria. In my mind, that's not really a
matching operator.

> Context: I don't understand the need of context in a client, I think the user > privilege should be only maintain in the hub. With my hub for example, it is > possible to have more than one "level" of operator with more or less > privilege (some op can "only" kick users but some others can also modifiy the > hub configuration). On connect, perhaps the hub should send a list of all > commands a client can send (IMHO, a bit heavy).

Yeah, I know the context concept is a bit heavy, but I think that it's
a good idea, nonetheless. That way, it will always be very clearly
defined which commands are valid.

The whole thing is that I want to stay as far away as can ever be
possible from the state machine stuff used in current DC
implementations. Like the current client-to-client protocol - if you
don't send the commands in the exact right order, the client will
simply stop responding. I think that's ugly and repulsive, and this
will more or less force people into building better implementations.

It also makes it easier to extend the protocol, as I stated in the
document. The client could request an extra context for some specific
commands, and if that context is implemented in the hub/peer, then all
is good, otherwise it isn't. It's a very clear way of doing it, in my
mind.

Please continue to have your say on this.

> References:
> =========
> > DESC: someone still uses a 32bit integer to store the share ? ;)

Nah, I don't really think so. I just thought that some lesser
programmer might decide to make a DC implementation, so I wanted to
make it clear from the very start.

> About connection stage, I assume GUID is the first command you sent (correct > me if I am wrong). Why not having the following connection establishment:
> > 1: H=>C: the hub sends its ID (something like the GUID of the client but for > the hub)
> > 2: C=>H: the client sends its ID and its password simultaneously (I modified > your "GUID ID" command into "GUID ID password"). Then we can do the full > authentification in a single step and without error, thanks to the GUID of > the hub
> > 3: H=>C: the hub accepts an continue the process into "normal" mode or close > the connection after a message.

Again, my utter goal is to avoid this state machine stuff. Such a
thing as a "first command" should not be defined. It is equally OK to
send any command that is part of the `identify' context, be it DESC or
GUID. The important thing is what should be done, not in what order.

Fredrik Tolf