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

Chris McDonough chrism at plope.com
Mon Jul 25 20:00:55 EDT 2005 

On Tue, 2005-07-26 at 09:44 +1000, Dylan Jay wrote:
> So to summarise:
> 
> - ClockServer is a good idea to put in the core but needs to made python 
> only.

Yes, at least for inclusion into Zope.

> - Schedular from cvs is probably the best one to use but not neccerily 
> in the core.

Not sure about "best" (because I've never really used any others) but I
have the opinion that we should hold off on that for the core, yes.

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

Yup.  The simplest way it can work is by putting the CVS scheduler's
"notify" method in a path in zope.conf.  This implies that the scheduler
has received a "time event" for "now".  If you wanted to get more fancy,
and you were into events you could create another script or product that
actually sent a "time event", and the ClockServer could call that.
There's almost no reason to do this if all you want is the scheduler,
though.

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

It's now officially on my todo list for 2.9.0 (along with blobs, and
maybe "zodb connection policies").

- C


> 
> 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  <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
> > 
> > 
> > _______________________________________________
> > Zope-Dev maillist  -  Zope-Dev at zope.org
> > http://mail.zope.org/mailman/listinfo/zope-dev
> > **  No cross posts or HTML encoding!  **
> > (Related lists - 
> >  http://mail.zope.org/mailman/listinfo/zope-announce
> >  http://mail.zope.org/mailman/listinfo/zope )
> > 
> 
> _______________________________________________
> Zope-Dev maillist  -  Zope-Dev at zope.org
> http://mail.zope.org/mailman/listinfo/zope-dev
> **  No cross posts or HTML encoding!  **
> (Related lists - 
>  http://mail.zope.org/mailman/listinfo/zope-announce
>  http://mail.zope.org/mailman/listinfo/zope )
>

More information about the Zope-Dev mailing list