Tim Bray reports on the 2008 O'Reilly Concurrency Summit a bit. Hopefully there will be more from Tim or others. The summit looks like an "open space" conference, scheduled on the spot by the attendees. Apparently the topics included REST and Erlang, and so the discussion must have branched out into distributed systems, not just concurrency per se.
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.Yeah, I think it's helpful to compare and contrast the two (HTTP and Erlang's own message passing). Also comparing and contrasting XMPP and Erlang's message passing is useful. They are three different, but related, points in the spectrum. (I wonder if XMPP came up at the summit? Is it bright enough on the radar yet?)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.
e.g. XMPP's "presence" capability is similar to Erlang's node linking, but more rich.
Neither HTTP nor XMPP have the selective, pattern-matching, message receive capability of Erlang. But they both would support multiple "channels", which can be used for similar purposes.
2 comments:
Not entirely apples to apples, but if you're in Java you can get some pattern matching-like structures around XMPP packet types. For example, in the integration we did for an upcoming release, we filter by IQ packet type. Keeps the packet-handler code smaller and more focused.
Now, if only I can find a way to get IQ replies mapped to a Scala actor receive :)
"Now, if only I can find a way to get IQ replies mapped to a Scala actor receive :)"
Clearly you need an existential type for that! Or was that a monad? Erm...
Post a Comment