Steve Vinoski’s Blog

Shell scripts as web services? Perhaps an obvious question, but hasn’t this capability already been around for about 15 years?

When I spoke at QCon San Francisco last November, Stefan Tilkov interviewed me, and the video is now available on InfoQ.com.

We covered a range of topics: CORBA, dynamic languages, REST, distribution, concurrency, Erlang. Stefan asked some great questions, and I hope I gave some worthwhile answers. Thanks again, Stefan.

I figured the decentralized media types idea that Stefan Tilkov and I each wrote about recently couldn’t be all that simple. So, not surprisingly, it turns out that at least Mark Baker (and according to Mark, also Mark Nottingham (mnot) as well), Bill de hÓra, and James Snell don’t like it. When either Mark or Mark speaks on matters pertaining to the web, I listen; I’ve been around each of them long enough to know that when they aren’t sure whether something is a good idea, it’s definitely worthwhile to take the time to understand why. I don’t believe I’ve ever met Bill or James in person, but I read their blogs for a good reason, plus James just got his blue belt so I’d like to avoid getting on his bad side. :-)

I particularly like Stu Charlton’s opinion on the matter, though, in part because he acknowledges the tension between the needs of the Internet vs. those of intranets.

At the end of the day, I understand the various explanations for why decentralizing media types is not a good idea after all, and I agree with them. I was unaware that mnot had already tried to go down this path. I see this issue as another stop along the way to a more thorough understanding of REST, and bringing it up has gotten some good technical explanations out in the open, where perhaps more people can see them and learn from them. Thanks to those mentioned above for providing those explanations, and to Stefan for kicking off the discussion.

In RESTful systems, media types define the formats of data exchanged between client and server. Standard media types are centrally registered and managed via the Internet Assigned Numbers Authority (IANA). If none of the registered IANA media types fits your application, you’re free to write up and submit a new one that does.

Less than one week ago I was wondering to myself why media types are centrally managed when the web typically prefers decentralization. I was therefore pleasantly surprised today when I read Stefan Tilkov’s posting on this very topic. The proposed solution he describes, from Sanjiva Weerawarana, Paul Fremantle, Jonathan Marsh, and James Clark, is pretty much in line with what I was thinking: register a new media type that has a URI parameter for identifying an actual data description. Very simple and yet potentially extremely effective.

I like this approach for several reasons beyond just the decentralization win. First, this allows us to gain experience with new media types before they’re standardized. Second, this augments rather than replaces the current IANA registration approach, and doesn’t break the existing IANA registration process in any way. Third, it doesn’t break or otherwise negatively impact any existing applications.

So, enough emailing and blogging about it — who’s going to write it and submit it to the IANA? I hereby offer to pitch in and help in whatever way I can.

Since a number of people seem to be experimenting with adding Erlang-style concurrency to other languages, Ulf Wiger has written a nice explanation of what Erlang-style concurrency actually is. Definitely informative.

On a related note, I chuckled when I saw this posting from Robert Virding, who helped create Erlang, in the erlang-questions list about a month ago:

After reading the blogs about how good Erlang’s concurrency model is and how we just just made a super implementation of it in XXX I have been led to formulate Virding’s First Rule of Programming:

Any sufficiently complicated concurrent program in another language contains an ad hoc informally-specified bug-ridden slow implementation of half of Erlang.

This is, of course, a mild travesty of Greenspun but I think it is fundamental enough to be my first rule, not the tenth.

I can understand where he’s coming from. When I see the kind of blog postings he’s referring to, I always wonder why they don’t just use Erlang itself instead of trying to reinvent it in another system whose design trade-offs are unlikely to be able to support it. Well, I guess it would make sense in the case where they’re specifically studying various implementations of concurrency, but other than that, I don’t get it.

On another related note, I found the comment below in another blog. It refers specifically to my own use of Erlang:

it’s [sic] be interesting to see how Steve mix [sic] Erlang and HTTP, since Erlang is asynchronous in nature and does not have any “resource” concept and HTTP’s sweet spots are just the opposite

That’s easy. If you want to experience HTTP as implemented in Erlang, just go to the Yaws website, which of course is powered by Yaws itself. As Ulf’s blog posting explains, Erlang message passing is asynchronous, but that really has nothing to do with Erlang’s ability to support protocols like HTTP. For example, when I was learning Erlang, given my CORBA background I wrote a subset of IIOP, and it was really quite easy. Furthermore, Erlang doesn’t need a “resource” concept to support HTTP. A resource in that context is, after all, ultimately just a chunk of code that processes incoming requests, and of course Erlang can do that.

If you want to know more, go pick up Joe Armstrong’s Erlang book — it’s quite excellent.