[Zope-dev] Re: Event Timer Service for Zope 2.8
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 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
Re: [Zope-dev] Re: Event Timer Service for Zope 2.8
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.
Re: [Zope-dev] Re: Event Timer Service for Zope 2.8
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 )
Re: [Zope-dev] Re: Event Timer Service for Zope 2.8
On Fri, 2005-07-22 at 13:11 +0200, Florent Guillaume wrote: Dylan Jay [EMAIL PROTECTED] wrote: Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris' ClockServer removes the need for such a thread, by hooking ZServer's mainloop to generate the faux request needed to kick off async processing. A crontab - like schedule can be driven equally well from ClockScheduler as from a separate thread. So what's wrong with including ClockServer in the core or making it easier to install? (ie not having to put packages in the python path which is hard with some hosting arrangements) And what's the argument against a core scheduler regardless of a clock? Isn't running background tasks a common need amoungst many very different tools and therefore a interstructure issue? 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. I wouldn't be apt include the Scheduler product in the core. I think it may be a tad too complicated. The Event product is likely superseded by the Zope 3 event system included in Five. - 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] Re: Event Timer Service for Zope 2.8
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 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. 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 - 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 )
Re: [Zope-dev] Re: Event Timer Service for Zope 2.8
Dylan Jay [EMAIL PROTECTED] wrote: Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris' ClockServer removes the need for such a thread, by hooking ZServer's mainloop to generate the faux request needed to kick off async processing. A crontab - like schedule can be driven equally well from ClockScheduler as from a separate thread. So what's wrong with including ClockServer in the core or making it easier to install? (ie not having to put packages in the python path which is hard with some hosting arrangements) And what's the argument against a core scheduler regardless of a clock? Isn't running background tasks a common need amoungst many very different tools and therefore a interstructure issue? Myself I'm for having ClockServer in the core, if Chris and others agree. Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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] Re: Event Timer Service for Zope 2.8
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dylan Jay wrote: Tres Seaver wrote: Chris' ClockServer removes the need for such a thread, by hooking ZServer's mainloop to generate the faux request needed to kick off async processing. A crontab - like schedule can be driven equally well from ClockScheduler as from a separate thread. So what's wrong with including ClockServer in the core or making it easier to install? (ie not having to put packages in the python path which is hard with some hosting arrangements) Hmm, I thought I was arguing *for* including ClockServer in the core; what I don't want is some of the alternatives which rely on running special threads. And what's the argument against a core scheduler regardless of a clock? Isn't running background tasks a common need amoungst many very different tools and therefore a interstructure issue? I could see including the Scheduler product as well, although there are some issues for long-running tasks which might not fit well (conflicts on the schedule itself are possible). Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC4Qr++gerLs4ltQ4RAg/BAKC9jzLSZ/CnMpDpKm7F+p2Wbm9CTACdEXgd c4gpIBSEXNa1gu3XDfF+JbQ= =DQrV -END PGP SIGNATURE- ___ 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] Re: Event Timer Service for Zope 2.8
Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris' ClockServer removes the need for such a thread, by hooking ZServer's mainloop to generate the faux request needed to kick off async processing. A crontab - like schedule can be driven equally well from ClockScheduler as from a separate thread. So what's wrong with including ClockServer in the core or making it easier to install? (ie not having to put packages in the python path which is hard with some hosting arrangements) And what's the argument against a core scheduler regardless of a clock? Isn't running background tasks a common need amoungst many very different tools and therefore a interstructure issue? ___ 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] Re: Event Timer Service for Zope 2.8
Chris McDonough wrote: On Sat, 2005-01-29 at 05:49, Andrew Veitch wrote: I noticed there was a thread last month on an event service for Zope. Did that reach any conclusion? From what I can see the present products are: - http://www.zope.org/Members/lstaffor/Xron - Zope 2.6 only, not being developed - http://zope.org/Members/naumen/NauScheduler - shipped with one of the Zope CMS's works fine with 2.7 - http://dev.legco.biz/products/ZopeScheduler and http://dev.legco.biz/products/timerservice - works fine with 2.7 too - http://cvs.zope.org/Products/Event/ - event service without a time service, not sure of development status - http://mail.zope.org/pipermail/zope-cmf/2005-January/021747.html - Dieter's project to be based on Python's sched module - http://api.nuxeo.org/CPS3/public/ CPSCore.EventServiceTool.EventServiceTool-class.html - CPS's event service - http://cvs.sourceforge.net/viewcvs.py/*checkout*/mailmanager/ mailmanager/MailCheckThread.py?rev=1.15 - our custom scheduler for MailManager - Zope X3's event service It has proven (at least for me) to be useful to make the distinction between event service, scheduler, and clock in the past. I tend to think of each this way: Event Service: Framework software that allows objects to communicate between each other indirectly by sending and receiving events. An event service's responsibility is only to receive and send messages. Note that it is not within the scope of an event service's responsibility to run tasks at timed or scheduled intervals. Scheduler: Software that ensures tasks may be run at timed or scheduled intervals. Clock: Software that intermittently pokes Zope, telling it to wake up and do something every so often. A scheduler needs a clock. A clock can be implemented either as an external source (e.g. wget every 10 seconds) or internally (by coopting the asyncore loop). Schedulers usually require clocks, but neither clocks nor schedulers require event services. Similarly, event services require neither a clock nor a scheduler. It would be great to some consolidation of all of this into the core. I would also strongly favour a timer service along with the event service. I know that the argument has always been that operating systems provide time services but this is not very convenient for cross platform development and on some Windows platforms it's difficult. If we use the definitions above, I think what you want is a scheduler and a clock to be available for Zope, but not necessarily an event service. Don't want to be pedantic about it, but when you use the term event service it tends to mean different things to different people. To that end, I'd suggest using the Scheduler product at http://cvs.zope.org/Products/Scheduler. Note that this product *does* currently depend on the Event product at http://cvs.zope.org/Products/Event but it's only by accident (the Event product is usable separately). There is an external clock implementation that ships with the Scheduler product. I agree with you that there should be a Zope internal clock. I created one not too long ago, but it's a bit invasive. Read http://www.plope.com/Members/chrism/more_scheduling and http://www.plope.com/Members/chrism/scheduling_service for an overview of the strategy I was thinking of when I did it. Personally, I think maybe the internal clock service can also be implemented as a Product and not added to Zope proper. It would be great if someone were to maybe volunteer to take the work that I did towards it and productify it. +1 for using http://cvs.zope.org/Products/Scheduler I think the time of a non-core scheduler needs to come to an end. Its crazy the number of implementations out there.\ I'm using the zope cvs version and I've enhanced it to make it serialised and non reentrant. I'd like to check that in. In order to simplify installation I do think a Product version of a clock would be required. Perhaps the clock can optional be promoted from outside to ensure its thread is still alive? I'm willing to have a crack at it as long as that effort isn't going to yet another non-core scheduler/clock. Dylan. ___ 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] Re: Event Timer Service for Zope 2.8
Chris McDonough wrote: On Sat, 2005-01-29 at 05:49, Andrew Veitch wrote: I noticed there was a thread last month on an event service for Zope. Did that reach any conclusion? From what I can see the present products are: - http://www.zope.org/Members/lstaffor/Xron - Zope 2.6 only, not being developed - http://zope.org/Members/naumen/NauScheduler - shipped with one of the Zope CMS's works fine with 2.7 - http://dev.legco.biz/products/ZopeScheduler and http://dev.legco.biz/products/timerservice - works fine with 2.7 too - http://cvs.zope.org/Products/Event/ - event service without a time service, not sure of development status - http://mail.zope.org/pipermail/zope-cmf/2005-January/021747.html - Dieter's project to be based on Python's sched module - http://api.nuxeo.org/CPS3/public/ CPSCore.EventServiceTool.EventServiceTool-class.html - CPS's event service - http://cvs.sourceforge.net/viewcvs.py/*checkout*/mailmanager/ mailmanager/MailCheckThread.py?rev=1.15 - our custom scheduler for MailManager - Zope X3's event service It has proven (at least for me) to be useful to make the distinction between event service, scheduler, and clock in the past. I tend to think of each this way: Event Service: Framework software that allows objects to communicate between each other indirectly by sending and receiving events. An event service's responsibility is only to receive and send messages. Note that it is not within the scope of an event service's responsibility to run tasks at timed or scheduled intervals. Scheduler: Software that ensures tasks may be run at timed or scheduled intervals. Clock: Software that intermittently pokes Zope, telling it to wake up and do something every so often. A scheduler needs a clock. A clock can be implemented either as an external source (e.g. wget every 10 seconds) or internally (by coopting the asyncore loop). Schedulers usually require clocks, but neither clocks nor schedulers require event services. Similarly, event services require neither a clock nor a scheduler. It would be great to some consolidation of all of this into the core. I would also strongly favour a timer service along with the event service. I know that the argument has always been that operating systems provide time services but this is not very convenient for cross platform development and on some Windows platforms it's difficult. If we use the definitions above, I think what you want is a scheduler and a clock to be available for Zope, but not necessarily an event service. Don't want to be pedantic about it, but when you use the term event service it tends to mean different things to different people. To that end, I'd suggest using the Scheduler product at http://cvs.zope.org/Products/Scheduler. Note that this product *does* currently depend on the Event product at http://cvs.zope.org/Products/Event but it's only by accident (the Event product is usable separately). There is an external clock implementation that ships with the Scheduler product. I agree with you that there should be a Zope internal clock. I created one not too long ago, but it's a bit invasive. Read http://www.plope.com/Members/chrism/more_scheduling and http://www.plope.com/Members/chrism/scheduling_service for an overview of the strategy I was thinking of when I did it. Personally, I think maybe the internal clock service can also be implemented as a Product and not added to Zope proper. It would be great if someone were to maybe volunteer to take the work that I did towards it and productify it. +1 for using http://cvs.zope.org/Products/Scheduler I think the time of a non-core scheduler needs to come to an end. Its crazy the number of implementations out there.\ I'm using the zope cvs version and I've enhanced it to make it serialised and non reentrant. I'd like to check that in. In order to simplify installation I do think a Product version of a clock would be required. Perhaps the clock can optional be promoted from outside to ensure its thread is still alive? I'm willing to have a crack at it as long as that effort isn't going to yet another non-core scheduler/clock. Dylan. ___ 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] Re: Event Timer Service for Zope 2.8
Dylan Jay wrote: Chris McDonough wrote: On Sat, 2005-01-29 at 05:49, Andrew Veitch wrote: I noticed there was a thread last month on an event service for Zope. Did that reach any conclusion? From what I can see the present products are: - http://www.zope.org/Members/lstaffor/Xron - Zope 2.6 only, not being developed - http://zope.org/Members/naumen/NauScheduler - shipped with one of the Zope CMS's works fine with 2.7 - http://dev.legco.biz/products/ZopeScheduler and http://dev.legco.biz/products/timerservice - works fine with 2.7 too - http://cvs.zope.org/Products/Event/ - event service without a time service, not sure of development status - http://mail.zope.org/pipermail/zope-cmf/2005-January/021747.html - Dieter's project to be based on Python's sched module - http://api.nuxeo.org/CPS3/public/ CPSCore.EventServiceTool.EventServiceTool-class.html - CPS's event service - http://cvs.sourceforge.net/viewcvs.py/*checkout*/mailmanager/ mailmanager/MailCheckThread.py?rev=1.15 - our custom scheduler for MailManager - Zope X3's event service It has proven (at least for me) to be useful to make the distinction between event service, scheduler, and clock in the past. I tend to think of each this way: Event Service: Framework software that allows objects to communicate between each other indirectly by sending and receiving events. An event service's responsibility is only to receive and send messages. Note that it is not within the scope of an event service's responsibility to run tasks at timed or scheduled intervals. Scheduler: Software that ensures tasks may be run at timed or scheduled intervals. Clock: Software that intermittently pokes Zope, telling it to wake up and do something every so often. A scheduler needs a clock. A clock can be implemented either as an external source (e.g. wget every 10 seconds) or internally (by coopting the asyncore loop). Schedulers usually require clocks, but neither clocks nor schedulers require event services. Similarly, event services require neither a clock nor a scheduler. It would be great to some consolidation of all of this into the core. I would also strongly favour a timer service along with the event service. I know that the argument has always been that operating systems provide time services but this is not very convenient for cross platform development and on some Windows platforms it's difficult. If we use the definitions above, I think what you want is a scheduler and a clock to be available for Zope, but not necessarily an event service. Don't want to be pedantic about it, but when you use the term event service it tends to mean different things to different people. To that end, I'd suggest using the Scheduler product at http://cvs.zope.org/Products/Scheduler. Note that this product *does* currently depend on the Event product at http://cvs.zope.org/Products/Event but it's only by accident (the Event product is usable separately). There is an external clock implementation that ships with the Scheduler product. I agree with you that there should be a Zope internal clock. I created one not too long ago, but it's a bit invasive. Read http://www.plope.com/Members/chrism/more_scheduling and http://www.plope.com/Members/chrism/scheduling_service for an overview of the strategy I was thinking of when I did it. Personally, I think maybe the internal clock service can also be implemented as a Product and not added to Zope proper. It would be great if someone were to maybe volunteer to take the work that I did towards it and productify it. +1 for using http://cvs.zope.org/Products/Scheduler I think the time of a non-core scheduler needs to come to an end. Its crazy the number of implementations out there.\ I'm using the zope cvs version and I've enhanced it to make it serialised and non reentrant. I'd like to check that in. In order to simplify installation I do think a Product version of a clock would be required. Perhaps the clock can optional be promoted from outside to ensure its thread is still alive? I'm willing to have a crack at it as long as that effort isn't going to yet another non-core scheduler/clock. Another not listed is a Zope3 scheduler that came from a sprint thats also back ported to Z2 http://www.last-bastion.net/ZScheduler Is this what we should be using? We really really need a core scheduler or at least one product should win out somehow. ___ 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] Re: Event Timer Service for Zope 2.8
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dylan Jay wrote: Chris McDonough wrote: On Sat, 2005-01-29 at 05:49, Andrew Veitch wrote: I noticed there was a thread last month on an event service for Zope. Did that reach any conclusion? From what I can see the present products are: - http://www.zope.org/Members/lstaffor/Xron - Zope 2.6 only, not being developed - http://zope.org/Members/naumen/NauScheduler - shipped with one of the Zope CMS's works fine with 2.7 - http://dev.legco.biz/products/ZopeScheduler and http://dev.legco.biz/products/timerservice - works fine with 2.7 too - http://cvs.zope.org/Products/Event/ - event service without a time service, not sure of development status - http://mail.zope.org/pipermail/zope-cmf/2005-January/021747.html - Dieter's project to be based on Python's sched module - http://api.nuxeo.org/CPS3/public/ CPSCore.EventServiceTool.EventServiceTool-class.html - CPS's event service - http://cvs.sourceforge.net/viewcvs.py/*checkout*/mailmanager/ mailmanager/MailCheckThread.py?rev=1.15 - our custom scheduler for MailManager - Zope X3's event service It has proven (at least for me) to be useful to make the distinction between event service, scheduler, and clock in the past. I tend to think of each this way: Event Service: Framework software that allows objects to communicate between each other indirectly by sending and receiving events. An event service's responsibility is only to receive and send messages. Note that it is not within the scope of an event service's responsibility to run tasks at timed or scheduled intervals. Scheduler: Software that ensures tasks may be run at timed or scheduled intervals. Clock: Software that intermittently pokes Zope, telling it to wake up and do something every so often. A scheduler needs a clock. A clock can be implemented either as an external source (e.g. wget every 10 seconds) or internally (by coopting the asyncore loop). Schedulers usually require clocks, but neither clocks nor schedulers require event services. Similarly, event services require neither a clock nor a scheduler. It would be great to some consolidation of all of this into the core. I would also strongly favour a timer service along with the event service. I know that the argument has always been that operating systems provide time services but this is not very convenient for cross platform development and on some Windows platforms it's difficult. If we use the definitions above, I think what you want is a scheduler and a clock to be available for Zope, but not necessarily an event service. Don't want to be pedantic about it, but when you use the term event service it tends to mean different things to different people. To that end, I'd suggest using the Scheduler product at http://cvs.zope.org/Products/Scheduler. Note that this product *does* currently depend on the Event product at http://cvs.zope.org/Products/Event but it's only by accident (the Event product is usable separately). There is an external clock implementation that ships with the Scheduler product. I agree with you that there should be a Zope internal clock. I created one not too long ago, but it's a bit invasive. Read http://www.plope.com/Members/chrism/more_scheduling and http://www.plope.com/Members/chrism/scheduling_service for an overview of the strategy I was thinking of when I did it. Personally, I think maybe the internal clock service can also be implemented as a Product and not added to Zope proper. It would be great if someone were to maybe volunteer to take the work that I did towards it and productify it. +1 for using http://cvs.zope.org/Products/Scheduler I think the time of a non-core scheduler needs to come to an end. Its crazy the number of implementations out there.\ I'm using the zope cvs version and I've enhanced it to make it serialised and non reentrant. I'd like to check that in. I'd want to see the rationale and the patch, first. The product keeps the schedule itself in the ZODB, which means that the transactional semantics are going to fight with several types of serialization. In order to simplify installation I do think a Product version of a clock would be required. Perhaps the clock can optional be promoted from outside to ensure its thread is still alive? I'm willing to have a crack at it as long as that effort isn't going to yet another non-core scheduler/clock. - -10 for incluing in the core any implementation which depends on the existence of a wild thread inside the appserver: coping with threads and async together is a *very* tricky dance, and when it goes south, you can't do anything to debug it, or fix it; all you can do is restart the appserver. Chris' ClockServer removes the need for such a thread, by hooking ZServer's mainloop to generate the faux request needed to kick off async processing. A crontab - like schedule can be
[Zope-dev] Re: Event Timer Service for Zope 2.8
Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dylan Jay wrote:
+1 for using http://cvs.zope.org/Products/Scheduler
I think the time of a non-core scheduler needs to come to an end. Its
crazy the number of implementations out there.\
I'm using the zope cvs version and I've enhanced it to make it
serialised and non reentrant. I'd like to check that in.
I'd want to see the rationale and the patch, first. The product keeps
the schedule itself in the ZODB, which means that the transactional
semantics are going to fight with several types of serialization.
The cvs.zope scheduler will run more than one task at a time which isn't
always desireable if they cause conflicts. I added a lock so that when
notify is called, it will not run if a task is still running. Of couse
this will only work on a single machine but I figure thats a fair enough
comprimise. I'm pretty sure the scheduler was also rerunning the same
event again if it had not finished before the next notify occured anyway
so that any longrunning process was causes a conflict error.
I couldn't see that these problems would cause any transactional
problems. I've included the changes if you want to have a look.
So is the cvs.zope scheduler the 'official' one? Will it be included in
any zope releases?
In order to simplify installation I do think a Product version of a
clock would be required. Perhaps the clock can optional be promoted from
outside to ensure its thread is still alive?
I'm willing to have a crack at it as long as that effort isn't going to
yet another non-core scheduler/clock.
- -10 for incluing in the core any implementation which depends on the
existence of a wild thread inside the appserver: coping with threads
and async together is a *very* tricky dance, and when it goes south, you
can't do anything to debug it, or fix it; all you can do is restart the
appserver.
Chris' ClockServer removes the need for such a thread, by hooking
ZServer's mainloop to generate the faux request needed to kick off
async processing. A crontab - like schedule can be driven equally
well from ClockScheduler as from a separate thread.
I was suggesting making ClockServer easy to install. At the moment its a
pain in the arse. Productise it as chris suggested. Is that not trivial?
Would ClockServer be acceptable to in the core?
Would the cvs scheduler be able to be changed such that ClockServer
could be selected as a clock source?
For real scalability, you need to make the long-running async processing
run in a separate process (and maybe a separate machine!): in this
case, you can:
Not sure what scalability has to do with it. Do you mean stability?
Dylan.
##
#
# Copyright (c) 2001 Zope Corporation and Contributors. All Rights Reserved.
#
# This software is subject to the provisions of the Zope Public License,
# Version 2.0 (ZPL). A copy of the ZPL should accompany this distribution.
# THIS SOFTWARE IS PROVIDED AS IS AND ANY AND ALL EXPRESS OR IMPLIED
# WARRANTIES ARE DISCLAIMED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
# WARRANTIES OF TITLE, MERCHANTABILITY, AGAINST INFRINGEMENT, AND FITNESS
# FOR A PARTICULAR PURPOSE
#
##
Scheduler module.
$Id: Scheduler.py,v 1.24 2003/07/10 01:42:57 tseaver Exp $
import os, time, sys, random
from types import FloatType, IntType, StringType
import threading
import Globals
from BTrees import IOBTree, OOBTree
from Persistence import Persistent
from ExtensionClass import Base
from Acquisition import aq_base
from AccessControl import ClassSecurityInfo
from ZODB.POSException import ConflictError
from OFS.SimpleItem import SimpleItem
from OFS.PropertyManager import PropertyManager
from Products.PageTemplates.PageTemplateFile import PageTemplateFile
from Products.Event.ISubscriptionAware import ISubscriptionAware
from Products.Event.ISubscriber import ISubscriber
from Products.Scheduler import IScheduler
from Products.Scheduler import IScheduledEvent
from Products.Scheduler import IDescheduledEvent
from Products.Scheduler import ITimeEvent
from Products.Scheduler.Task import Task
from Products.Scheduler.Task import InconsistentSchedulerMarkerTask
from Products.Scheduler.SchedulerPermissions import *
from zLOG import LOG, PROBLEM, ERROR, BLATHER, INFO
_NotifyLock = threading.Lock()
__version__ = $Revision: 1.24 $[11:-2]
class Scheduler(SimpleItem, PropertyManager):
meta_type = 'Scheduler'
manage_options = (
{'label': 'Current Tasks', 'action': 'manage_current_tasks'},
{'label': 'Schedule A Task', 'action': 'manage_schedule_tasks'},
{'label': 'Properties', 'action':'manage_propertiesForm'},
{'label': 'Security', 'action':'manage_access'},
{'label': 'Ownership', 'action':'manage_owner'},
{'label': 'Undo', 'action':'manage_UndoForm'},
)
