I *always* think Kamaelia is a great idea and I can *never* find an application where I can actually use it. It drives me nuts.
What part of kamaelia's generator model is new, exactly?
The bits I haven't used yet (which means all of it)! Even if the fundamental technique is as old as generators, the framework isn't (so new anyway)...
The Twisted stuff we demo'd will go up sometime over the next few days.. I'll drop a comment here when it is.
Python generators are inherently synchronous, and if you're using one, you have to understand its internal state to use it correctly. With kamaelia components, we add a mutable object (by embedding the generator as a method in a class), which has default inbound & outbound queues (inboxes and outboxes).
The generator method is always called "main", with a real life example here:
http://kamaelia.svn.sourceforge.....py?
view=markup
cf MailHandler.main
In practice in that app, for speed of dev I sketched out the core protocol as a basic component (MailHandler).
Added facilities for actually handling the SMTP protocol by subclassing that (ConcreteMailHandler). Then I subclassed again, adding code handling the greylisting policy (GreyListingPolicy). Finally that resulting protocol handler is subclassed in GreylistServer.protocol to allow it to be configured.
The interesting bits of code vs standard usage of generators are:
* MailHandler.main - the core loop handling the SMTP structure
* MailHandler.getline - miniloop for getting data from the SMTP client (this is a greylisting SMTP proxy/relay)
* ConcreteMailHandler.getline_fromsmtpserver - miniloop for getting data from the SMTP server we forward to.
* ConcreteMailHandler.handleDisconnect - forwards the mail to the real server.
* yield WaitComplete() - this tells the scheduler to run the given generator in place of the current one for a little while and return to us when done. (If yields were "nestable" this wouldn't be necessary)
That's probably the core of the difference - usage is asynchronous rather than synchronous. The upshot is more like CSP & unix pipelines programming than working with iterators. For high level components you just bolt them together and really don't need to worry about how they work or synchronise. (cf the pipeline for debugging at the end of the above file)
The above code depends on Axon & Kamaelia (in that order) from my scratch branch here and is IMO a little rough around the edges.
grabbable here:
svn co https://
kamaelia.svn.sourceforge....ate_MPS_Scratch kamaelia
browseable:
http://kamaelia.svn.sourceforge....te_MPS_Scratch/
(This greylisting code is currently running despamming my mail for me, when I get a chance to polish it, it'll be released seperately 
Commenting by HaloScan
