[TransWarp] PROPOSAL: refactoring of peak.running.daemons

[Phillip J. Eby]

At 03:24 PM 4/16/03 +0200, Ulrich Eck wrote:
>[snip proposal]
>
>i've worked with Jim Fulton on a Task Schedule for Zope3
>(meant to be a low-resolution Schedule e.g. once per sec/min/..)
>
>we designed a similar system as you're implementing and i wanted
>to give you a chance to look at the interfaces we defined:
>
>In our concept there play to parts:
>
>Schedule and Tasks


Interesting.  If you look at the checkins for this morning, you'll see I've 
already implemented basically this idea (I woke up with some ideas of how 
to cleanly and quickly implement yesterday's proposal).  The main 
difference is that PEAK's new IPeriodicTask doesn't do its own scheduling; 
(no 'schedule()' method) instead it provides an attribute value that is 
queried by the scheduler to determine when it should be rescheduled 
for.  (Also, there's no notion in PEAK of a principal to run the task as; I 
personally don't think that should be part of the scheduling core, but 
should instead be a specialized service or utility, so that the scheduling 
system isn't dependent on the security package.)

I'd strongly suggest that you and Jim take a look at the Twisted "reactor" 
interfaces (e.g. IReactorTime) and consider using them for Zope.  Twisted 
has a *very* clean and practical design, in addition to being implemented 
for lots of platforms and special case conditions as part of an overall 
event/scheduling loop.  Even if Twisted isn't going to be integrated for 
doing protocol servers, the interfaces are worth looking at.

Some of the interfaces you described also seem unclear as to whether the 
schedule is intended to be persistent or not.  For example, you mention 
BTrees, but then elsewhere there's a method to get all the scheduled tasks, 
which would seem excessive if it's a persistent schedule.