[Web-SIG] Web Site Process Bus

[Phillip J. Eby]

At 02:17 PM 6/25/2007 -0700, Robert Brewer wrote:
>Phillip J. Eby wrote:
> > At 01:51 PM 6/25/2007 -0700, Robert Brewer wrote:
> > >Seriously, though, this handles the notification but not the state
> > >machine, which I think is critical to the effort. It also
> > doesn't do any
> > >error-handling for misbehaving subscribers, so not all
> > subscribers are
> > >guaranteed to run if there's an unhandled error in an earlier
> > >subscriber.
> >
> > Again, it would be really helpful if you could provide some scenarios
> > that show why these things are important.  It's not immediately
> > obvious to me that they are.
>
>I replied with some in another email, it's just being slow.
>
> > For example, if an error occurs, isn't that an indication that the
> > component is broken?  Masking the failure just makes it less likely
> > the component will get fixed in a timely manner.
>
>Yes, the component is broken. However, at runtime, breakage in a
>CherryPy component shouldn't keep a Quixote component from, say,
>correctly freeing its DB connections.

In theory that makes sense, but in practice if you're using 
priorities because there is a dependency sequence involved, then you 
now have a new problem, since a component you're relying on having 
started or stopped first, is now violating its invariants.

I'm not opposed to logging or catching errors, but I am opposed (in 
the absence of more specific evidence) to allowing callbacks to 
propagate unhandled exceptions in the spec, or encouraging event 
senders to make heroic efforts in the face of unhandled 
exceptions.  Trying to recover from brokenness is generally not very 
likely to result in *less* breaking, IMO.


> > Meanwhile, if you get a start call, you must be starting, right?  So
> > why worry about the state?  It'd be simpler to just use
> > "before/during/after" messages the way Twisted does.  Your "block"
> > example could be replaced by waiting for the "after" message of the
> > desired state, for example.
>
>That's a possible way to go. My intention was to support both 1)
>examination of the state by external components (for operations other
>than 'block'--progress meters spring to mind) and 2) restrict some state
>transitions if necessary; for example, make bus.start() do nothing (or
>block) unless the state is "STOPPED".

Progress meters can be handled by callbacks, too.  As for the 
restrictions, who benefits?  ISTM that components need to manage 
their own lifecycles anyway and should be idempotent with respect to 
repeated transitions.

But I'll look for the use cases email before commenting further.  :)