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

[Ulrich Eck]

> 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.)

we had two reasons because we wanted to give the Task control over
scheduling:

1. avoid problems with long-running tasks, if they run longer than 
   their poll/reschedule Interval.

2. make it possible to chain tasks (e.g. if task X has finished schedule
   another task Y at some time)

these interfaces are very specific to zope3 used as persistent
utility/service .. so the principal is not of interest in peak.

> 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.

i have no information about the current state of Twisted integration,
but i'll have a look at that stuff.

> 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.

the system we designed is meant to be persistent .. so you're right it
should probably be iterTaskTimes instead.

the whole package is in an early prototype stadium

cheers

-- 
---------------------------------------

Ulrich Eck
net-labs Systemhaus GmbH
Ebersberger Str. 46
85570 Markt Schwaben - Germany

eMail: ueck <at> net-labs.de
phone: +49 8121 4747 10
fax:   +49 8121 4747 77