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)
   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?

Zope-Dev maillist  -
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to