[PEAK] Re: PEAK design pointers

[Phillip J. Eby]

At 03:29 PM 3/7/04 +0000, Paul Moore wrote:

>Hmm, I've read the events module, and as far as I can see it's aimed
>at a cooperative multitasking model. That doesn't seem to fit my
>application structure at all.

Actually, it does, since it's just a higher-level view of Twisted-style 
callbacks.  However, for your specific application, if you are skilled with 
Twisted already, and the tasks you want to achieve are relatively simple, 
it may not be worth you learning the 'peak.events' model.

Most of my uses of 'peak.events' are for things that have complex 
interactions and "temporal rules" like "if we get lots of requests, and we 
have less than the maximum number of processes started, then start more 
processes up to a goal level, but no more than one every N seconds.  If any 
processes die while we're trying to get to the goal level, keep starting 
processes.  If we reach the goal level, reset the goal level to the minimum 
number of processes."  That sort of logic is very straightforward to 
express as events.Task objects, but very very hard to do correctly with 
just plain callbacks.

If your top-level framework needs to do that kind of task management, you 
will probably sooner or later want to look at peak.events in more detail.