[Zope-dev] Re: Event & Timer Service for Zope 2.8

[Dylan Jay]

Chris McDonough wrote:
> On Fri, 2005-07-22 at 13:11 +0200, Florent Guillaume wrote:
> 
>>Dylan Jay  <gmane at dylanjay.com> wrote:
>>
>>>Tres Seaver wrote:

>>Myself I'm for having ClockServer in the core, if Chris and others agree.
> 
> 
> It's fine with me.  We maybe just need to remove the C extension in
> it... someone (you?) provided a pure python implementation of what it
> does that probably runs just as fast.

There is also TimerService by Nikolay Kim. Does that work in the same 
way? One nice feature of this is that products such as a scheduler 
subscribe to its tick so that many products can benifit from the clock. 
This seems more flexible to me, rather than putting the path to be 
called in the zope.conf.

Another nice feature is a plugin archetecture shown by
http://www.last-bastion.net/portal_zpydoc/Products.ZScheduler.html
Here one kind of clock can be replaced by another so for instance a cron 
job could be used instead of the clockservice. That product also had a 
singlethreaded clock that ensured the next tick didn't occur until the 
last finished. Personally I think that is the schedulers job rather than 
the clocks but I do think allowing an cron override is a good idea.
So perhaps the archetecture could look something like

ClockService (outside zope)
        v
Clock ControlPanel (inside zope... could also be called via cron wget)
    v                     v
Scheduler A          Product X

In other words products subscribe to the clock control panel in order to 
get a regular call back and the clock control panel is driver from 
clockserver or some other outside source.

Or alternatively you could just make the clock control panel a scheduler 
and say that anyone wanting a clock tick has to register a recurring task.


> I wouldn't be apt include the Scheduler product in the core.  I think it
> may be a tad too complicated.

Do you mean the zope cvs scheduler? I think this is the simplest 
implementation I've seen. It is API friendly in that it allows for code 
to add events reasonably easily. Its UI could be improved somewhat. The 
Zscheduler above as a nicer UI that could be borrowed.
I think the cvs scheduler needs to at least have an option of not 
allowing more than one task at a time to run. This could be implemented 
in the callers code but it is a nice service. At the very least the 
current code needs to be fixed as it causes conflicts if its notify is 
called before the last one has finished.

> The Event product is likely superseded by the Zope 3 event system
> included in Five.

Is there really a need for an event system? I can't see where the actual 
event system is even used in the cvs scheduler. Surely a listener/talker 
pattern is easy enough to implement?