[Zope3-dev] Event module as a file system service--ick?

[Gary Poster]

OK; I've been working with services, and the event service in particular.  My 
main task has been to create a rudimentary local event service.

I replaced the subscribe, unsubscribe, and publishEvent hooks in the Event 
module with the pattern I saw and followed in the ComponentArchitecture 
package.   These hooks add a context as the first parameter.  By default in 
the Event package, this context is ignored, but the local EventService 
overrides this functionality via the hookable system so that the hooks try to 
find the nearest placeful Event Service to work with first.  If the context 
is None or if there is no placeful event service above the context, they 
work with the global (file system) event service.  This seems clean,  
appropriate, and powerful.  

I registered the global event service with the main service manager.

Then, when I started running tests, I ran into a major oddity: I noticed that 
the Event module declared itself in the __init__ to implement IEventService.  
By changing the hooks to be contextually aware, I broke this facade of being 
able to "from Zope import Event" and treat the module as if it were the 
global service.  Some of the tests and a very little bit of code use the 
Event module in such a way.

To be honest, I don't like this facade much, and I'm personally happy to get 
rid of it.  Does anyone mind too much?  Is there a really good reason for 
this?  I think the Event Service should always be obtained by the 
ComponentArchitecture, if possible.

Gary