So to summarise:

- ClockServer is a good idea to put in the core but needs to made python only. - Schedular from cvs is probably the best one to use but not neccerily in the core.

Does the schedular work with ClockServer by puting the notify path in zope.conf or will the schedular need to be modified to subscribe to the clock?

So whats next? Does one put a feature request in the collector these days or is there another process?

Chris McDonough wrote:
On Sun, 2005-07-24 at 11:51 +1000, Dylan Jay wrote:

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?

I don't know.  As far as I know, ClockServer is the only product that
works as a medusa server as opposed to a separate thread or process
(which is really its only attraction).

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.

This is typically the domain of an event service (components subscribe
to events, and the service contacts all of them when one of those events
happens).  I agree this is very useful but I'd try to implement it in
terms of a more general event service.  The clock is really just a clock
and it should do not much more.

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.

That'd be fine but IMHO a scheduler should probably still be implemented
"on top" of one or more dumb clocks and clock ticks should cause events
to fire (if necessary) based on an event system that can be used for
other things.

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.

It also currently depends on the Event product (although that would be
easy to remove).

But FWIW, I'm not interested in putting any scheduler in the core
personally right away, just a clock for now.  This is mostly for
maintenance reasons.  If we did put one in, I'd probably try to
implement it in Zope 3 and bridge it to Zope 2 using the Zope 3 event
service and Five.

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?

The Scheduler product indeed subscribes to an event service in order to
accept "ITimeEvent" and "IScheduledEvent" event notifications.  See its
"notify" method in Scheduler.Scheduler.

The pattern is easy to implement but it is useful to have one component
handle event registration and notification so you don't have to
reimplement it over and over.

- C

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

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

Reply via email to