I spent quite a bit of today at the O’Reilly 2008 Concurrency Summit. It was a congenial crowd, but at the end of the day kind of a downer, because we have lots of hard concurrency problems and not too many solutions. Anyhow, two subjects that came up were REST (which is concurrent at the largest possible scale), and, unsurprisingly, Erlang. And it struck me that they’re kind of like each other.
Left to right: Larry Wall, Brent Gorda, Allison Randal, John Mitchell, Rob Bjornson.
Well, in REST, a message sender has to know the receiver’s address, there’s no global data, the receiver has to be waiting for the message, and the receiver will typically dispatch on its contents. Just like Erlang.
By the way, that picture’s at ISO 400 and 1/15 of a second, dig the anti-shake. The new camera is working out well.
Contributions
March 07, 2008
· Technology (90 fragments)
· · Concurrency (76 more)
· · Erlang (4 more)
· · Web (396 more)
· Technology (90 fragments)
· · Concurrency (76 more)
· · Erlang (4 more)
· · Web (396 more)
Comment feed for ongoing:
From: PJ (Mar 07 2008, at 19:23)
IIRC, both REST and Erlang can use DNS names for their receiver's address, so it's only mildly 'known', since whatever's doing the name resolution could change it (modulo whatever caching is done by the sender).
[link]
From: Bill de hOra (Mar 07 2008, at 20:10)
"because we have lots of hard concurrency problems and not too many solutions"
Go back and talk to your sales colleagure who said data is out of control - she was right. Managing data growth (all user generated) is problem number one as I see it. Concurrency is a side effect.
[link]
From: Robert Sayre (Mar 08 2008, at 17:06)
I dunno Bill. Sounds dangerously close to "concurrency is only a concern because we're trying to do lots of things at once".
[link]
From: Michael Sparks (Mar 10 2008, at 17:34)
For two other places where the comparison between mashups and concurrency has been made please look at these two presentations on slideshare.
The first is the more recent one, which I gave at Barcamp Manchester UK:
http://www.slideshare.net/kamaelian/sociable-software
which I decided to give the title:
Sociable Software (or “how you really already know how to make concurrency for multicore easy to work with”)
The second is a fair bit older, from Euro OSCON 2005, which covers a particular project in more detail:
http://www.slideshare.net/kamaelian/timeshift-everything-miss-nothing-mashup-your-pvr-with-kamaelia
3 other references on Kamaelia - which expounds this approach in a general language environment (currently python, but proofs of concept also exist in C++, Ruby & Java) are here:
http://kamaelia.sourceforge.net/Cookbook
http://kamaelia.sourceforge.net/Components
http://www.bbc.co.uk/rd/pubs/whp/whp113.shtml
Hope you find the links interesting.
[link]