On Fri, 2009-09-25 at 11:25 -0400, Anurag S. Maskey wrote: > > Stepping back a bit, I think our big concern > > is ending up in the wrong state - we're processing > > event A, and as a consequence move into > > state X, but meanwhile sitting in the event > > queue is a state change event moving us > > into state Y. Have I got this right? > Yep, that's exactly right. Furthermore, state X may not be reachable > from state Y, which I think is the main problem.
I pointed out these issues during the code-review (see seb-051, seb-052, seb-055, and seb-056). I don't believe that placing events that are dependent on object state on the event queue works given that events pending in the queue may modify the state. This means that at a minimum, there are no reliable error semantics associated with such events, and in addition, this leads to unexplainable transient errors that the user can't understand nor control that are caused by kinks in the implementation. I don't think that this is hard to fix, however. Can't most door calls simply be handled in-line? -Seb
