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 <[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 > >>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@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@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@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 )