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

[Chris McDonough]

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

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
> 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.

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? 

Yes.

> 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