March 2024 - This site, and Kamaelia are being updated. There is significant work needed, and PRs are welcome.

Recent Changes

Current status: This site is currently undergoing a number of updates and upgrades. After this the plan is to bring the Kamaelia codebase up to date relative to changes in the python eco system since the project was put on indefinite hold.

Why? This was a relative safe thing to do when the project was targetting python 2.7 since python 2.7 was an extraordinarily long lived supported version. Then the pandemic hit, and frankly, there were more important things to worry about. The pandemic is still with us, but circumstances have changed, making updates at the moment practical and realistic to achieve, so this has been done.

Upcoming changes

In no particular order:

Future

2024/02/11

(This page created today, adding some entries and dates below for an indication of activity)

Over the past 2 months, on and off, work has been done on the following areas to start bringing this site back up to speed:

Before 2023/12/15

The project was on hold in a "the things we're using aren't broken so this isn't being updated" state. Kamaelia had been used in a number of small projects internally while the project was in this state, but there were few public updates.

There were minor fixes to the DVB subsystems (2016).

2014-2022 - Guild

Most effort in this space has actually gone into Kamaelia's follow on project Guild which focussed on a "syntactic sugar" first approach. Guild was not heavility advertised, but was used internally in a number of projects. For example it was used in the micro:bit prototype to implement the batch compiler in the python to arduino-C++ toolchain. To give an idea of timeframe of activity there:

Future work on Kamaelia will probably relate to bringing the best ideas from Guild into Kamaelia and allowing the use of Kamaelia components in guild systems.

Why mention Guild and resurrect Kamaelia?

This section needs editting down, or perhaps shifting off to a blog

Why mention Guild here? While this is the Kamaelia site, not the guild one, guild was very much intended as a follow on from Kamaelia. It's intention was very much "OK, we've proven that can work, can we make it work with a nice syntax?". As a result, Guild started from a "syntactic sugar first" approach, but the aim was always to unify the two projects. This never actually happened, but probably will at some point.

To cut a long story short, I figured out a way of doing a guild type syntax in C++. From a kamaelia perspective a C++ version has always been possible. This was first demonstrated in a C++ MiniAxon from as long ago as Feb 2005. I recently benchmarked the generators that used relative to C++20 coroutines, and found that ancient code was remarkably good.

Also, since starting Guild, I've become increasingly aware that actually formally publishing this stuff would be useful. For example, this approach of having outboxes - which was first in Kamaelia, and then reused in Guild actually seems pretty unique, especially from the perspective of seeking to simplify development for novice users. This was noted by Ted Leung in an O'Reilly keynote in back in 2009.

The point being though, Kamaelia isn't really a CSP system (which to an extent inspired Kamaelia though async hardware & network systems were the core). This point was raised at an early Pycon UK and the person noting it said "you're doing actor systems". At the time I didn't know an awful lot about actor systems, so I went away, and thought "maybe I can use that idea for syntactic sugar"

So that inspired Guild. Kamaelia was put on hold for various reasons, but primarily because I noted that while begineers could start, get up to speed with kamaelia and do interesting things, there was a reticence from experienced developers. I figured then that syntactic sugar was the way forward. Then life got busy and we all got allocated to different projects.

Kamaelia pretty much sought to ask the question "can you build systems like this?" Guild pretty much sought to ask the question "Can you make this readable and friendlier to experienced developers?" My current question is "can I generalise this across different languages and gain significant performance gains, and later down the line interoperability?".

Then I realised that I could implement Guild like sugar in modern C++ and I got re-interested. This time I did a literature search (ACM, Springer, etc) to see if anyone had done this. To my surprise, no.

Please note though, there are some really awesome things in the actor world at the moment, and the two that spring to mind are Pony and Akka. If you’re interested in looking at actors more, those are great starting points. There are also a number of high performance actor systems in languages like C++, but I personally feel that readability and ease of use are vital. (And those two "soft" aspects don't tend to apply to languages like C++ :-) - and I use C++ daily as well as python these days...)

Why resurrect Kamaelia? The upshot from this, is that I thought "this all needs formally publishing and talking about", primarily because I've now got code over 20 years old that is still useful today because of Kamaelia's separation of concerns.

Yes, Kamaelia could do with a root and branch update. Many subsystems could do with Guild style rewrites, but the code and systems tend to just work. The core version of Kamaelia Grey - the greylisting server that handled my email for over a decade (until I abandoned running my home sever) was written in an afternoon, and tweaked over a few days following.

The point is this combination of flow and actors hasn't really been talked about in the literature, as far as I can tell. Not in the way used in Kamaelia and Guild and not really from the perspective of ease of use, and clarity of systems. So publishing struck me as a good idea.

That led me to revisiting fixing the Kamaelia site, and leads me to rethinking interoperability between the two - especially given the changes in the python language since Kamaelia started.

-- Michael, 12/2/2024 (needs editting down)