Web Things, by Mark Baker

I had saved my email, both sent and received, since 1996, kept safe in a series of mbox files which I’ve diligently moved from hard drive to hard drive as I’ve upgraded my PC. Of course, it wasn’t very accessible there, and it certainly wasn’t integrated with the last four years of mail kept in Gmail (well, half in GMail proper, and the other half in Apps). So I was happy to read, albeit belatedly, that Google had added email migration to Apps.

I knew what had to be done, so I dug into the documentation looking for a way to have it inhale those mbox files. As well as the obvious POP/IMAP support, they also supported an Atom interface, which is great and all the rage and everything, but come on, is the low hanging fruit solution here not for me to just email the mbox files? Anyhow, without that option, it turned out that the simplest route was just to install dovecot and have it serve up each file as an IMAP folder … which took all of 5 seconds to configure. So I pointed Google at the server, and it spent the next half-day or so chugging through files.

I’m now a happy man, as the last 12 years of much of my communication with the world is now searchable.

Needless to say, I’m a fan.

Once again I’m happy to be a part of the program committee for the DOA conference. I’ve found the quality of papers there to always be quite high … yes, even some of the Web services ones often have something to contribute (I can forgive one wrong assumption 8-).

The CFP for DOA 2008 has just been posted. Please consider submitting.

Opera’s surely been feeling the heat from WebKit given that it’s basically taking over the world, including mobile. So here’s a thought: why don’t they abandon their own rendering engine, Presto, and adopt WebKit? Then instead of being “that other browser”, which developers are loathe to bother testing for, they’d be the best (from what I’ve heard of Safari) WebKit based browser out there. Seems a no-brainer to me.

Dear LazyWeb;

I’m still undecided about which pill I’ll swallow when I finally upgrade my ancient-but-reliable laptop. But whatever my choice, I realize I’m going to have a large problem, the same problem that inflicts so many other laptop-toting, standards-wrangling, conference-schmoozing geeks like myself: I’ll need a whole new batch of stickers! What I was thinking would be nice would be a service that let me create my own cover, digitally, and then would print it out on some kind on thin, sticky clear laminate in the size I needed, perhaps like an Invisible Shield (which has been great on my N95, BTW).

Hey, it looks like Web3S was replaced by Atom/APP. Awesome. I think “Why not Atom?” was one of my first questions of Yaron when he described Web3S to me last year. I’m confident this is for the best. In addition to Atom/APP being existing standards (with an accompanying abundance of existing tooling), Microsoft will also gain the evolutionary advantages of the hypermedia as the engine of application state constraint, which Web3S opted to replace with a schema-driven application model.

Kudos to everybody involved in that decision.

David Peterson defends SimpleDB’s use of HTTP GET for mutation actions by appealing to the HTTP spec itself, specifically pipelining where it says;

Clients SHOULD NOT pipeline requests using non-idempotent methods or non-idempotent sequences of methods (see section 9.1.2). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to send a non-idempotent request SHOULD wait to send that request until it has received the response status for the previous request.

His argument is that because POST isn’t idempotent, that it couldn’t be used for pipelining, and therefore that GET could be used. There’s two fatal flaws with this argument however. The first is that PUT is idempotent, and is also a mutator, so you can pipeline that no problem (modulo the concern about sequences of requests). The second is that if both the client and server understand that an “Action” parameter specifies the actual action to be taken (overriding the HTTP method), then if Action specifies a non-idempotent method, you’re still going to run into the same indeterminism problem that the HTTP spec warns against: what matters is the effective method of the message, not only the HTTP method.

It’s also interesting that the example Dare uses is of an Action value “PutAttributes”, which is presumably idempotent, doh!

Nope, Amazon blew it, again. I’ve offered them my services a couple times already, but they’ve not taken me up on my offer yet. They really, really(!) should before they publish another service.

A much more interesting question to me is whether PATCH will operate at the content level or the transfer level. Or, to put it anther way, will patch operate at the infoset level, or will it be able to be directly applied to HTML as she is written?

PATCH means what ever the spec says it means. Anything else is a function of either the diff media type in use, or the particular implementation of the server that processes the message.

Roy Fielding joins the blogosphere. Subscribed (duh!).

Via Stefan, a proposal from the WSO2 gang for an approach to decentralizing media types and removing the requirement for the registration process.

Been there, tried that. I used to think that was a good idea, but no longer do.

Problem one: an abundance of media types is a bad thing for pretty much the same reasons that an abundance of application interfaces is a bad thing; the more that is different, the more difficult interoperability becomes. We need less, more general media types, not more specific ones.

Problem two, specific to their solution for this “problem” (which is “application/data-format;uri=http://mediatypes.example.com/foo/bar”): media type parameters don’t affect the semantics of the payload. This solution requires changing the Web to incorporate parameters in this way. Consider, if an existing firewall was configured to block, for example, image/svg+xml content. If SVG were also assigned its own “media type URI” and delivered using application/data-format, that firewall wouldn’t be able to block it. Oops.

Problem three (which mnot convinced me of): having your media type reviewed by the capable volunteers on ietf-types, is a good thing. Sure, you could still do that while using a decentralized token/process, but I consider having motivation for review built-in to the mechanism a feature, not a bug, especially given problem one above.

Update; here’s an older position of mine.