[Web-SIG] Web Site Process Bus

[Robert Brewer]

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. The Bus implementation I posted
logs every failure, and then raises the last one. If we need more
notification than a site log, I think that can be added, either with an
optional argument to bus.log(), or with a custom subscriber to the 'log'
channel.

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


Robert Brewer
System Architect
Amor Ministries
fumanchu at amor.org