Chris McDonough wrote:
On Fri, 2005-07-22 at 13:11 +0200, Florent Guillaume wrote:
Dylan Jay <[EMAIL PROTECTED]> 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
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)
Clock ControlPanel (inside zope... could also be called via cron wget)
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?
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -