[Web-SIG] Web Site Process Bus

[Ian Bicking]

Phillip J. Eby wrote:
> At 04:42 PM 6/25/2007 -0500, Ian Bicking wrote:
>> Phillip J. Eby wrote:
>>> At 02:28 PM 6/25/2007 -0500, Ian Bicking wrote:
>>>> Potentially a Zope-style minimal event framework would work.  Maybe 
>>>> something like:
>>>>
>>>>   send_signal(signal_name, signal_data)
>>>>   subscribe(signal_name, listener)
>>> That was what I was wondering, too, except I was thinking it would be 
>>> sufficient to use entry points for subscription, but only invoke the 
>>> entry points whose modules are in sys.modules.  In other words, never 
>>> actually import a module in order to invoke a callback.  That way, 
>>> subscription is a natural side effect of importing the modules that 
>>> contain the listeners.  Something like:
>>> def send_signal(group, name, *args, **kw):
>>>     for ep in iter_entry_points(group, name):
>>>         if ep.module_name in sys.modules:
>>>             ep.load()(*args, **kw)
>>
>> I don't think that makes sense for this case.  The way I imagine using 
>> it is:
>>
>> class MyApplication(object):
>>
>>     def __init__(self, db):
>>         self.db = db
>>         subscribe('reload_resources', self.reload)
>>     def reload(self, data=None):
>>         self.db.close()
>>         self.db.open()
> 
> 
> I guess I wasn't clear.  The point is that the approach I'm suggesting 
> allows event subscribers to be decoupled.  A library could have an 
> "on_reload" function, for example, that references a library-specific 
> event system.  Some frameworks, after all, are going to have their own 
> event systems.
> 
> So a bridge from the bus to zope.event, for example, could just create 
> objects and notify() them, and frameworks that are okay with depending 
> on zope.event can use that.

I think it's just using pkg_resources functionality so that you don't 
need a common thing to subscribe to.  Which I guess is exactly why 
Robert wants this idea of different buses instead of a single bus; 
though it's vague to me how you plug the buses and listeners and whatnot 
together without some common code or place to put objects (entry points 
being one possibility, a single module with these functions another).  I 
guess you could have an entry point that indicates objects that want to 
know about any buses that are created.  It seems like a lot of 
indirection, though.

>> That is, I subscribe one particular thing when it is applicable, not 
>> because the library is on the system.
> 
> That's why the code I suggested only invokes entry points that are 
> *already imported* -- i.e., that someone is using.

Just because the module is imported doesn't mean that every case in the 
module exists.  E.g., in my example only on the instantiation of 
MyApplication would I listen for the event.

This means that the subscription has to be done even if no one emits the 
signal.  Which is possible if you start listening for lots of different 
things because we can't agree on names and you want to support lots of 
systems.  But I don't think that's going to happen.


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