[Web-SIG] Web Site Process Bus

[Ian Bicking]

Phillip J. Eby wrote:
> At 10:57 AM 6/25/2007 -0700, Robert Brewer wrote:
>> This should be a collaborative effort, and I'm very open to
>> discussion at all levels of detail. Even if this flies at the highest
>> conceptual level, there are still several things I know of we would need
>> to nail down:
>>
>>  * States. For example, do we need an EXITING state? If so, we should
>> probably rename STOPPED to IDLE.
>>  * State transitions: do we need to lock or block which Bus methods can
>> be called, depending on the current state?
>>  * Standard non-state channels, such as signals. Do we want a 'status'
>> channel (for e.g. zdaemon)?
>>  * Should bus.log take other args, like 'severity'? Should it assume a
>> stdlib logging API?
>>  * Should bus.log be replaced with separate stdout and stderr instead?
>>  * ...and just to introduce a bikeshed, is there a better name for the
>> spec effort than "WSPB"?
>>
>> I have lots of other questions, but I'll let you all ask them.
> 
> I have some more basic questions...  like, how do you know you need 
> to subscribe in the first place?  Who does the subscribing?
> 
> My initial reaction is that I like the general idea, but the idea of 
> having a bus *object* seems wrong to me somehow.  Perhaps because the 
> only way to get it seems to be in an already-running application, 
> which seems to sort of defeat the purpose.  But maybe my purposes are 
> different than yours?
> 
> Perhaps if you could present some example scenarios to show how you 
> see this actually being used...?

I'm also confused about what this is about.  Or maybe it feels like it's 
about more than one thing, and needn't be.  The blog post kind of helps 
and also kind of confuses things.

For instance, doesn't atexit work fine for exiting?  (Not in mod_python, 
but I still don't know why it *shouldn't* work in mod_python.)  Of 
course, there isn't anything for other signals, and creating something 
for those would be quite useful.  Potentially a Zope-style minimal event 
framework would work.  Maybe something like:

   send_signal(signal_name, signal_data)
   subscribe(signal_name, listener)

Where in the second case, listener(signal_name, signal_data) is called, 
and signal_name can be used to automatically filter, or None to receive 
all signals.  I prefer strings for the names, because then there's no 
dependencies (you don't have to import anything, you just have to have 
packages agree on names).  I think Zope doesn't have any high-level 
filtering (?) and generally uses interfaces for filtering in the 
listener itself.

Anyway, given that we still would need to define the signals we care 
about in the web context, but it's not too terrible hard I think.

Maybe the "bus" you are talking about that is registered is the 
thing-that-sends-signals?  I think it can simply be a single 
module/library that we all agree to use.

Anyway, this mostly seems like what you are describing.  I guess when 
viewed as an event publishing system, there's other concerns that pop up 
-- can you cancel the event?  (Ugh, I don't think so; I think GUI events 
and signals are something fairly different from what we're talking about 
here).  Also, should exceptions propagate?  I feel vaguely like they 
should, but I'm not sure.

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