eric writes:
> > > 1:
> > C->H: GUID xxx
> > H->C: ACCP
> > C->H: DESC xxx
> > H->C: WELC
> >
> > 2:
> > C->H: DESC xxx
> > H->C: ACCP
> > C->H: GUID xxx
> > H->C: WELC
> >
> > 3:
> > C->H: GUID xxx1
> > H->C: ACCP
> > C->H: GUID xxx2
> > H->C: ACCP
> > C->H: GUID xxx3 (note that this will be the authoritative one)
> > H->C: ACCP
> > C->H: DESC xxx
> > H->C: WELC
> > but this remains a state machine (even a very simple one):

Oh yes, most things can be described as a state machine. There are two
main things with these contexts, though.
First of all, the semantics is not that of a state machine. While a
context can be described as a state machine, I did not mean for it to
be thought of as one. The thing is that all commands within a single
context are always valid, no matter what commands were sent
earlier. As you said yourself, it can be described as a state machine,
but the semantics that underlie the notion of a context is not that of
a state machine.
Second, there can be several contexts valid at a single time. Sure,
this can still be described as a state machine, but the abstraction
that lies in the notion of a context simplifies the overall picture.

The thing is that I want to avoid these state machines that, in your
words, have "dead ends". That is why I want the thought of having a
certain set of commands that are valid at a specific time, and that
the effect of these commands are primarily on data, not on the set of
commands that will be valid after the command has been executed.

As you can see, both ways of implementing it can easily be transferred
into the other, but what I want to achieve is semantics, not
implementation.

I hope I made myself clear, although I doubt it a bit. =)

> Can you give an example with a password. I'd like to know at which time you > reject invalid login and/or invalid password.

Sure. I'll include the context changes in this example:

(Connection accepted, the active contexts are `base' and `identify')
C->H: guid xxx
H->C: accp
C->H: desc xxx
H->C: npwd noecho "Password: " (I'm thinking a PAM-like scheme right now)
(The `npwd' reply has an implied context change, that removes the
`identify' context and adds the `auth' context. Sure, a kind of state
machine, but with different semantics. The active contexts are now
`base' and `auth')
C->H: pass " Secret "
H->C: fail (If the hub really didn't like the client, it can close the
       connection now, although `auth' remains in place, so if the
       hub _doesn't_ close the connection, the client can try again.)
C->H: pass "  Secret "
H->C: welc
(The `welc' reply has as implied context change that removes `auth'
and adds `main'. Thus, the active contexts are now `base' and `main'.)

At least this is what I have had in mind.

Fredrik Tolf