[Web-SIG] Web Site Process Bus

[Ian Bicking]

Phillip J. Eby wrote:
> 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 anti-priorities.  It's hard to arrange all those priorities in some 
useful way, and I don't see the purpose.

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

There's also the weird situation where the exception raised depends on 
what the last subscriber is, or priority, or what components are loaded, 
or something like that depending on the implementation.

I might be inclined to turn the exception into another event.  Maybe:

def publish(self, channel, *args, **kw):
     subscribers = self.subscribers.get(channel, [])
     for subscriber in subscribers:
         try:
             subscriber(channel, *args, **kw)
         except:
             if channel == 'error':
                 raise
             exc_info = sys.exc_info()
             self.publish('error', subscriber, exc_info, (channel, args, 
kw))

In testing you could add a listener for 'error' that would just raise 
the exception, so that errors are never hidden in that case.  But 
otherwise, when there's code from different sources (e.g., a server 
hosting Moin, a Pylons app, etc) I'd rather one of those not be able to 
mess up the other too easily.

-- 
Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org
             | Write code, do good | http://topp.openplans.org/careers