[Stackless] Server Components
Michael
ms at cerenity.org
Fri Mar 28 16:32:31 CET 2008
On Friday 28 March 2008 13:18:31 Simon Pickles wrote:
> SO - Am I reinventing the wheel?
Of course you are - you wouldn't ask the question otherwise :-) The question
is "are you inventing a better wheel"? That's a harder question - that's one
you can answer, not me :)
> Does Twisted do this, or other
> Frameworks? In my limited experience, I need to create a server hub then
> have all the component modules connect to that as clients.
Twisted tries to avoid multithreading and multiprocess, so you're probably
working in an independent space. However it might be worth you thinking how
you can work with twisted rather than in competition with twisted. ( It may
take a bit of thought, but I suspect it's doable :)
That's kinda where Kamaelia fails - since for some dumb reason people think
it's competition with twisted, even though it's aim is rather different. It's
probably because we started from the starting point of "How do we make
concurrency easier to deal with for the average maintainer since we're making
a network server" (which was the original goal), rather than "how do we use X
to build a network server". The problem is that was taken as competition with
twisted. (I did give a particularly bad lightning talk once which probably
didn't help)
Anyhow, kamaelia does do networking stuff in a communicating sequential
things kind of way (which stackless does of course as well), so hopefully the
rest of this is more relevant...
> Is there a better way?
I don't know if it's better, but you may want to look at what we've done in
Kamaelia. We use generators to build the majority of our components, but do
also have thread based & process based components. Each communicates to the
outside world using the same API of inboxes & outboxes (akin to stackless's
channels), and these are implemented differently depending on the concurrency
mechanism used.
* Generators use standard lists
* Theads uses Queue.Queue's
* Processes use Paul Boddies pprocess module and the channel's he
implemented.
Our networking code lives in the following places:
https://kamaelia.svn.sourceforge.net/svnroot/kamaelia/trunk/Code/Python/Kamaelia/Kamaelia/Chassis/ConnectedServer.py
https://kamaelia.svn.sourceforge.net/svnroot/kamaelia/trunk/Code/Python/Kamaelia/Kamaelia/Internet
Now you may dislike the coding style or like it. But hopefully it's useful. It
would be REALLY interesting to see someone create a Stackless base component
as well, and if you're interested in doing that, our tutorial which teaches
beginners to python how to build their own core generator based system is
here:
http://kamaelia.sourceforge.net/MiniAxon/
... since we've often created mini-axon's when building a new concurrency
mechanism (or working on optimisations/restructures).
Random aside: if a student wants to do something related to this sort of thing
as part of Google's Summer of Code, please put an application in under BBC
Research, since Kamaelia is the main focus there. I've put a suggestion of
stackless integration & twisted integration up on our ideas page, but it's
probably a good idea to mention it here...
Realising-thats-a-little-more-random-than-it-could-be-ly,
Michael.
--
http://yeoldeclue.com/blog
http://kamaelia.sourceforge.net/SummerOfCode2008
advice for GSOC apps:
http://yeoldeclue.com/cgi-bin/blog/blog.cgi?rm=viewpost&nodeid=1206709783
More information about the Stackless
mailing list