Nouanda writes:
> Yeah, it allow client to send only the modified part of its
> information...and hub broadcast. (Actually, we need to send the whole MyINFO
> each time we connect/disconnect to a hub for example)

Well, that I have already described how to do.

> For the order part, it was just an example of what we can't do. We
> need to remember the order of all arguments, and imho, it's not
> very important (and little annoying)

While the order admittedly has no value in itself, it is the most
bandwidth-saving way to designate the role of the arguments, since it
takes no extra bandwidth at all. The extra penalty of having to
remember the order of the arguments isn't really that bad anyway, if I
may have my say (it's not really that hard... ;-) ).

Also, if this reordering part only is important for the description, I
could very well consider changing the syntax of that command instead,
such as having arguments that are word-pairs instead, the first
describing what the second is, like this:

desc nick "My nick" tslots 3 fslots 3 share 0...

In fact, that might actually be better than the current syntax, since
it's also more extensible. It's also very much like the syntax that
you described first, only that it only applies to the `desc' command.

The fact remains, that most commands in the DC protocol doesn't need
to be very extensible, and then it is my opinion that it might be
wiser to save the bandwidth that is required by a more complex
protocol. I'm fairly sure that hub owners can agree with me.

> Exactly the same thing for the order of commands sent from client
> to hub (or client to client). Order is not important, important
> thing is at least, destination have all information needed.

I agree about completely. I'm very much against enforcing a strict
order in which commands must be sent. That is something that I have
emphasized very much in my latest mails.