Over on the FP twitter, there’s a mention of something named “Worq”. As work on that project progressed, a new name suggested itself which was more descriptive and — more importantly — less twee. That name is Roundabout, and this post will tell you what it’s all about.

It’s a message-passing framework. Or, if you prefer, a toolkit for building applications on the microkernel model.

Message-passing systems are an extreme form of software modularity and decoupling, sitting a step or two beyond object orientation on that notional scale.

The components of such a system don’t “own” each other and don’t make subroutine or method calls into each other. Instead they pass requests and responses back and forth as peers. It’s not unlike AJAX-y web programming: you have no idea what’s on the other end of an XMLHTTPRequest, you just know that there are things you can request and that you’ll get back a bundle of data or an error of some sort.

There are really big wins in software re-use and reliability here, but it comes at the cost of nontrivial resource usage.

In Roundabout’s design, specifically, there’s a decent chunk of memory overhead in the form of a router process which will automatically be spawned for every Roundabout app. There will also be some amount of performance cost due to the time spent shuffling messages back and forth, but this should be negligible on a human timescale, where most applications operate. (Of course, testing and profiling will be done to assess and minimize this cost.)

I believe that these costs have kept message-passing systems from becoming popular due to programmers’ long-ingrained resistance to “profligate” resource usage, even as we create user-facing apps which can eat hundreds of megs of memory just to sit idle.

I further believe, however, that the real win from Roundabout will be making more complex and powerful applications far simpler to write and maintain, and that this will be well worth the fairly small cost in resources.

There are no examples yet, and I don’t wish to make promises which can’t be kept, but the goal is to make Roundabout have nearly zero programmer overhead. The API should be as minimal, simple, and invisible as possible.

All that said, it is, of course, not a silver bullet. It’s just one more option which, hopefully, will be useful to have in our toolkits.

We’ll see how it goes. The protocol spec and reference implementation spec are being worked on currently, and code will be written once they are complete.