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
- 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
CPSCore.EventServiceTool.EventServiceTool-class.html - CPS's event
mailmanager/MailCheckThread.py?rev=1.15 - our custom scheduler for
- 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:
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.
Software that ensures tasks may be run at timed or scheduled intervals.
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/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.
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -