Carl-Adam Brengesjö writes:
> 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 :/

I never intended for contexts to be sent back and forth, unless
explicitly desired. I have intended for many commands to have implied
context changes. The "strict order" is exactly what I have wanted to
avoid, since it's so extremely inflexible. For example, if you send
commands out-of-order in the existing client-to-client DC protocol,
the peer usually stops responding or disconnects. In that case, why
even have command names to begin with? What good would ever come from
requiring that one command be sent before another when there is no
apparent meaning of the order (ie. why would you want to _require_
that GUID be sent before DESC when it can just as well be made the
other way around)?

What kind of more specific replies is it that you want? ACPT is just
the basic idea of the command having been executed as it was expected
to. Exceptional events are indeed handled through other replies.

>  > 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 get a reply indicating that the command wasn't accepted, then
why is that? Isn't it actually because it was sent in the wrong
context? Since the hub apparently has to have some kind of idea of
concepts anyway (or it wouldn't know whether to accept or deny a
command), why not actually standardize it, so that all implementors
know what is valid at what point?

Also, in my mind, contexts also allow for easy extensibility to the
protocol. Instead of sending commands to probe whether or not they are
valid, the client can request a certain context and see if the hub is
willing to give it. In that way, it also shows the hub's
capabilities.

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

Since I want to define contexts as a means of extending the protocol,
having a set number of maximum contexts would be a bad idea.

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

I wasn't just planning on using it for adding more operator
"levels". I invented it to do anything. For example, if you make a hub
and a client that support a very specific search request, a specific
context could be used to identify that as well.

I think that extensibility is always of the essence, since we want a
flexible protocol this time.

Fredrik Tolf