Back to work after a long Pentecostes weekend. To Harald, >My understanding of a generator is "something that yields" Yes, generators are functions that yields. So, it's possible to be back in a later time after having yield a request or something else ( an object or another generator). >But all my quixote-programs end immediatly after serving a request - what can >not take more than 3 seconds; but normally is finished quite faster than >0.01seconds. Performance is not my key point. Instead, I'm more focused towards some sort of task flow oriented solution. The system may know where the user has been before and therefore can emulate a recursive behavior between cgi requests. To Graham, Although it's possible (and i did at the begining) to implement this based on q_lookup without extending any base class, I thought the session publish class would be the more natural place to fit it. >Is your collection of generators truly a stack? Is the >stack/tree/collection available to all sessions? Or does a unique >session map onto a single collection of generators? As it's not a mature idea yet, i would explain what i've done for my purposes. The last is the true. A session holds his own collection of generators. That could be extended in a later time, but i'm not sure what it implies exactly. It's not precisly a stack as the 'scheduler' can pass through its information , but it could be used mainly to implement recursive function calling. >Have you experienced any clean-up/performance issues? >Could you post (a link to) your code and perhaps a 'hello, world' example. Sorry but i don't still feel confident enough with the code, but i'm working wiht it. I hope soon cuold i satisfy this. The prior mail was a first contact in order to introduce the idea and to receive some feed-back/ complaints / contributionts to help me clarify and to extend it. And that's still the current point at issue. >I forget what the sun looks like! Here,after a 5 hours trek above 2000 mts., the sun in june may look like a big hammer. Oscar