A mini-axon using processes would be equally lightweight (shorter probably) and pretty awesome.

Also, it’s easy to confuse the two halves of Kamaelia. If you think of Kamaelia as just an actor-type implementation, then it’s actually more an actor-like implementation, with STM & an internal SOA system of just over 2000 lines (which is how big Axon actually is, excluding comments & docs), with 80,000 lines of examples…

However, personally I view it as a mechanism for building components which happen to be best used in a concurrent fashion. ie rather than viewing it as “a mechanism for using concurrency”, I view it as “OK, assume we have concurrency, how can we use this to assist in building and maintaining systems”. Axon also gives you the tools for taking these concurrent systems, and interfacing between concurrent systems and standard code. (http://www.kamaelia.org/AxonHandle)

As a result, I view Axon as a library which provides you with the tools wrapping up idioms useful for building collections of components which be a framework.

Anyway, potato/potato, tomato/tomato — if you like, you like, if you don’t, you don’t.

I’d love to replace our existing process based stuff btw with a multiprocessing based version though. If I was going to go down this route, I’d follow our mini axon tutorial to do so, largely becauseit’s essentially the starting point I took with the multiprocess stuff recently and it worked out pretty well.

Beyond this basic stuff though, I’ve noted that people generally start talking about co-ordination languages and building up pattern repositories. The interesting intersection between these two which you get if you call things components rather than actors is it becomes natural to create components called a chassis. These chassis often instantiate directly in concrete usable form concepts that you’d normally refer to as a pattern — Pipeline, Graphline, Carousel, Backplane, Seq, TPipe, etc.

On a random note, you may want to check out MASCOT “Modular Approach to Software Construction, Operation and Test”. I heard about it late last year, and it appears to have the same sort of architecture as Kamaelia. Interestingly (to me) it makes the same key decision — when you send a message outside your component, you don’t know who is going to receive it. This then enables (and requires) a higher level system for connecting components together. The upshot is highly reusable components. This doesn’t entirely surprise me — my ethos came from recognising that asynchronous hardware systems & network systems look strikingly similar… (cf http://www.slideshare.net/kamaelian/sociable-so…)

Anyway, reference for MASCOT: http://async.org.uk/Hugo.Simpson/ — skip down to the end of the page for this PDF: http://async.org.uk/Hugo.Simpson/MASCOT-3.1-Man… I was really pleased to be pointed at MASCOT, largely because it showed a large number of other domains where the same basic model has been used for well over 30 years… Just with non-existent exposure, and slightly different metaphors. Though we, like it, also have mechanisms for automatically visualising systems, with a 1:1 correspondence. Beyond that this also gives us a model that matches Edward Lee’s “The Problem with threads” — we’d released running code long before that paper was published :-)

Anyway, I’m glad that you’re looking at what we’ve done. If you use it, that’d be great, and I’ll happily merge anything you’d like to have a life. (the only comment I’d make there is metaphors and accessibility count — this is surely the point of python? :-) If you don’t take what we use etc but it helps you solidify your thoughts to “No, I don’t want that, I want this”, then likewise, I’m equally glad. If you do that, I’d love to know what you do try, since I like to merge best practice concurrency ideas into Axon :-)

I’d *REALLY* suggest looking at MASCOT though. Really made my Christmas last year when I was pointed at it.

We’re currently having lots of fun using concurrency, primarily by allowing it to make our lives easier, and forgettable about :) It’d be nice to see something similar on top of multiprocessing (which we’ll do if you don’t, but it’d be great if you did — but I’d understand if your view was that you prefer a pure actor (sender knows receiver) model.

Another implementation which could be included in Kam. which is built on top of 2.6 would also be good — my eventual goal is to work with people like Adam Olsen (http://code.google.com/p/python-safethread/) to get a prototype for something that may one day be included in python-core (in the multiprocessing package itself)

Right now, it’s just a series of jumbled thoughts in my head: I’m not excluding anything, and I’m for learning from any given implementation

1) Yes, I am talking about a base for an Actor/Monitor implementation.
2) My point, inaptly expressed, was that Kamelia has already proven that it can work over a multiprocess abstraction — and Axon already looks a lot like an Actor implementation. Accordingly, it might be interesting to use Axon/Kamelia to build an Actor implementation on top of the now-to-be-widely-available multiprocessing package. Multiprocessing would be the lowest level, Axon above it.

cheers,
sebastien.

The only reason I am thinking about doing an Actor/Monitor implementation is as an experiment, I’m not suggesting it for python core.