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