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