[Zope-dev] Scheduler product, anyone?

[Loren Stafford]

I just discovered sched.py. What I want to create is a Zope-ish version.

> >
> > 1. Cron runs a Dispatcher method via RPC.
> >
> > 2. Dispatcher looks in schedule table, finds next scheduled
> method in table,
> > and runs it as a separate transaction (could use RPC), and
> removes the entry
> > from the table.
>
> It may be possible to do this from within Zope and not involve cron
> at all. Your Scheduler product could fire off a seperate thread
> when its package is first loaded. Has the advantages of only attempting
> calls when Zope is running, and being platform independant.

Great idea! However I can't quite get my mind around the implementation in
Zope:

1. Starting the Dispatcher on Zope start-up.
The only place I can think to put this kind of initialization logic is in
__init__.py of the product.
That code would have to look for any already-created instance and (if found)
run it's Dispatcher method in a separate thread. Is there any way to do
this?  I have a feeling I'm confused on this point. I seems odd for
__init__.py to look for instances.

2. Does it make sense to provide for more than one instance of the
scheduler? I can't think of a reason. But then you couldn't prevent someone
from creating as many as they want, could you?

3. Managing separate threads.
Will Zope's persistence and transaction mechanism provide all the mutual
exclusion I need on the schedule queue? ...or do I need some kind of lock?


>
> > 3. Schedule-aware objects can use the Scheduler method to
> schedule one of
> > their methods for execution at a given time.

> Why the requirement for being schedule-aware? I personally would
> want an interface that could be used from arbitrary DTML, external
> methods or python methods using aquisition:

You're right; there is no need for schedule-awareness. It's gone from my
spec.

-- Thanks, everyone, for the helpful ideas,
-- Loren