Atomic Monday

Herewith some evidence, for the general tech public, that Atompub is a big deal, and for the Atomistas, some interesting developments.

It’s an Atompub Future · Let’s see; Microsoft is using Atompub for... well, everything, pretty much. Google has been for a while, and that’s now leveraging Salesforce.com. Oh, and the Kool Erlang Kids are getting into the act: Atom-PubSub module for ejabberd (Hmm, I dislike “Atom PubSub” and all its orthographic variations). And then there are things like AtomServer.

The Right Amount of Cloud Lock-In · But here’s the real reason. We seem to have consensus that the future is cloudy. My #1 gripe with the cloud-computing infrastructure I’ve seen out there is that it all seems to come with some degree of lock-in.

The only appropriate amount of lock-in, to build a cloud-centric future, is zero.

It seems to me that Steve O’Grady really hit the nail on the head with Question for Cloud Campers: The Cloud and Standards. Now it’s quite possible that my obvious bias as one of Atom’s fond parents is showing here, but it seems to me that the Atom format provides a nice clean zero-lock-in way of getting information out of the cloud, and Atompub an equivalently safe way in.

Now let’s move on to some Atom-technology news stories.

Atom-Multipart · To post an image (or any other bit-blob) with Atompub, you HTTP-POST it; the server stores it and creates a synthetic Atom entry for metadata about it. Then if you want to update the metadata, you have to PUT that. So Joe Gregorio, based on his work at Google, is proposing “atom-multipart”; the idea is use pack up your bit-blob and an Atom entry full of metadata, and push ’em at the server in a MIME multipart package.

Everyone seems to like the idea, the Atom-protocol mailing list is chewing it over, the IETF seems to think it’s appropriate for the standards track, and I’ve volunteered to be the consensus referee (which is probably poetic justice since I’m obviously going to have to implement the sucker in mod_atom).

Meta-CRUD · Just to review: an Atompub implementation lets you create, retrieve, update, and delete (CRUD) Web Resources. So, suppose you think of publications as Web Resources, wouldn’t Atompub be a candidate for the CRUD job? Now, this is all getting more than a little bit meta, but the idea is so obvious that everybody is doing it. In fact, I’m doing it myself in mod_atom, since my original idea (to create a new publication, edit the Apache config file) is, well, really lousy.

I thought “If everyone’s doing this, maybe we should standardize it, and then authors of Atompub test suites (like me) could build portable tests”. So I raised the issue on the mailing list and well, it’s complicated.

Just by way of reminder: Atompub starts with a Service Document, which contains one or more named Workspaces, which contain Collections, which are what you actually POST to in order to start up the CRUD process.

So the meta-idea is simple; have a collection that when you POST to it, creates a new publication. What could be simpler? Well, it turns out that there are three obvious choices you could take as to what happens when you POST to one of these meta-collections:

1. Create a new Service Doc, with Workspaces and collections.

2. Create a new Workspace in the current Service Doc.

3. Create a new collection in the current Workspace.

There are implementors out there doing all three of these things; mod_atom does #1. We just don’t have enough experience yet to decide which (if any) of ’em deserve standardization. Oh well.

---

---

Contributions