Fredrik Tolf wrote:

Essentially, a state machine where you must send GUID first and then
DESC is like this context engine, only that it has even more contexts
and even more implicit changes. Therefore, I think this is clearer,
more flexible, and also allows for human input error when eg. typing
in a Telnet session. Also, since all contexts are named, that gives a
very strict definition of the protocol - there can be no doubts
anywhere about when you should/could send what.

At least that is the idea I had behind it.

Instead of sending contexts forth and backward, isn't is just simplier to have a strict order to send the commands? And/or more specific reply messages instead of `ACPT' for every kind of command :/

> 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.

Why bother? If the command isn't valid just reply with a message that he/she are not authorized to use it (you gotta have such a message anyways) And if you mean to disable the function to send the command at all from the client, the client could aswell `detect' if it has been given operator status.

If you use context, use binary flags instead of string names - you can save alot of bandwidth - instead of 18 bytes ("base,main,operator") you have just 2 bytes (in a text protocol, 1 byte if we can cheat) (using table described below).

base     0
identify 1
auth     2
main     4
operator 8

base|main|operator = 12

And last, about adding more operator `levels' - dont! I can only see the usage of adding a `voice' (vip), and a global operator level if channel support are going to be supported.
Adding too many of userlevels in the protocol don't allow much of the customization that is available to DC today regarding user modes/access.

/Carl-Adam