WLW+AtomPub, Part 1: Autodiscovery

16Oct07

When things are working properly, Windows Live Writer only requires the user to know three pieces of information to configure a blog: the blog homepage URL, the username, and the password. Even the most novice bloggers should be able to answer those questions, and there’s no technical reason why we should ask more of anyone.

Of course, to actually post to a blog, we also need to know what blogging APIs are supported and where the endpoints are. For MetaWeblog-based protocols, the standard protocol for “autodiscovering” that information from the homepage is RSD.

Configuring an AtomPub blog needs to be equally easy. For some reason, people in the AtomPub community don’t seem to like RSD (only Six Apart puts Atom endpoints in RSD). We need another autodiscovery mechanism.

Update Oct 16 2007, 8:42 AM: Sam Ruby and then Daniel Berlinger [inventor of RSD] have weighed in. Sam created a patch that adds Atom to WordPress’s RSD. Hmmm, maybe we didn’t need another autodiscovery mechanism after all. In fact, RSD nicely solves the “class=preferred” problem below.

Not to pick at old wounds, but here’s the thread that made me think RSD wasn’t going to fly with the Atom community. I forgot the specifics last night and was too lazy to go hunt the thread down.

Add a link to your service doc

There’s no official IETF standard for AtomPub autodiscovery, but there seems to be rough consensus among implementers that a link to the service document should be included in the <head>:

<link rel=”service” type=”application/atomsvc+xml” href=”” />

(Please pretend the curly quotes are straight quotes; WordPress does that automatically.)

AtomPub or MetaWeblog?

If your blog homepage has both RSD and a service doc link in the <head>, Windows Live Writer will generally take the RSD (in other words, it will use AtomPub only if a MetaWeblog-based protocol isn’t available). There are two separate ways to force Writer to prefer AtomPub instead.

  1. Add the attribute class=”preferred” to the AtomPub service link element. (If your server actually does speak AtomPub better than MetaWeblog, this is what you should do.)
  2. Start WindowsLiveWriter.exe with the command line argument /preferatom. (This is intended to make testing convenient for server implementers.)

Note that these only have an effect at configuration time–that is, only when you are adding a new blog or updating the configuration of an existing blog (Weblog | Edit Weblog Settings | Update Account Configuration).

Other links?

While you’re at it, you might consider also adding a link for the collection feed URI, and on permalink pages, a link for the entry’s edit URI. In earlier drafts of the AtomPub spec, they look like the following, respectively:

<link rel=”service.post” type=”application/atom+xml” title=”…” href=”…” />

<link rel=”service.edit” type=”application/atom+xml;type=entry” title=”…” href=”…” />

The next version of Writer won’t look for these links, but it’s easy to imagine features we could add in the future if they were available. Then again, since these were pulled from RFC5023 and don’t appear in any other spec, there may be some valid disadvantages to this approach that I’m not aware of. Any standardistas out there want to chime in?



11 Responses to “WLW+AtomPub, Part 1: Autodiscovery”

  1. Will the WLW user experience differ for the XML-RPC and Atompub user? Or have you managed to hide all that?

  2. I’ll second Tim’s question; I don’t fully understand the whole preferences thing. Or rather, I think it is backwards. Permit me to explain.

    WordPress RSDs currently state that the implement and prefer the WordPress API, but will accept pretty much anything, without picking favorites.

    From a WLW point of view, that basically is saying that if you don’t support their API, what you pick is entirely up to you. Which, frankly, is as it should be.

    Now, I assume that 98%+ of the time, there really is no difference. And the <2% case, the differences are ones that a typically WLW user won’t fully comprehend at installation time. Which, from my point of view, puts you in the unenviable position of having to make an informed choice based on the information in the RSD (including, for example, pattern matching on the engineName if you know that product X’s implementation of AtomPub is somewhat feature constrained, and product Y’s implementation of MetaWeblog is to be avoided at all costs).

    Either that, or figuring out a way to explain the differences in terms that your audience can appreciate.

    As I said, unenviable.

  3. I agree with Sam. You can’t make a qualified choice of API at the time of installation without fully informing the user of each API’s pros and cons. That will probably take hours and the user will have moved on to another desktop blogging client by then, so that probably isn’t a very viable option.

    If the blog server prefers an API; pick that one, if not; pick the API WLW prefers. Then let the user go into the options at any time and change the API if he wants to (but perhaps disable the API options the server doesn’t support), but don’t harass the user with these choices at the time of installation.🙂

    Now, when it comes to autodiscovery, RSD is probably a good enough solution. And discovery of links at the individual post level can probably be solved by finding the URI to the atom:entry and in that find the atom:link[@rel = ‘edit’].

  4. Sam, Asbjørn: Well, let me point out that right now, the WordPress API and Movable Type API both trump AtomPub in terms of features. For that reason alone, unless specifically told otherwise we would always choose one of those over AtomPub.

    For this release, we would also prefer MetaWeblog over AtomPub, even though they are roughly equal in functionality. That’s simply because our MetaWeblog implementation has been battle tested, whereas our AtomPub client impl has not.

    You’re right, though, that a boolean “preferred” attribute is not very useful if you don’t recognize/support the one API that the server has decided is preferred. Maybe it needs to be more of a continuum of preferredness? If you have more concrete ideas, let me know.

    In the worst case, we wouldn’t consider it too much of a burden to have to “know” the best APIs to use for the top dozen or two blog engines and services. We already do similar stuff for everything from title encoding, to timezone conversion, to inserting videos. It’s a dirty job, but somebody’s got to do it🙂

  5. Tim: The configuration and publishing experiences are just about identical–you won’t be able to tell the difference. During editing, the only difference is that not all of the features that are available to, say, WordPress API are available for AtomPub. Extended entries, native tags/keywords, hierarchical categories, comment policy, pingback & trackback policy, trackback URLs, and post passwords… and probably others that I can’t think of.

  6. Thanks for your elaborate reply, Joe. I would ask one more thing from you, though. Could you please, in more detail, explain what shortcomings AtomPub has when compared to the different proprietary APIs? I understand that this is quite a lot to ask and that it might take plenty of time. But it’s important for AtomPub’s future as I see it to meet the requirements of the different blog tools out there, even if this ultimately means writing a new specification (though I doubt that’s necessary at this point in time).

    A place to start would be the Atom Protocol mailing list, and we could perhaps move on from there to the Atom Wiki or something to enumerate what the shortcomings are and how they can be remedied. As Tim mentions in his latest blog entry “End of a Chapter” (http://www.tbray.org/ongoing/When/200x/2007/10/23/End-of-a-chapter):

    “f everyone is going to be willing to code their clients to work with every different set of publishing-system idiosyncrasies, then Atompub will have been a waste of time.”

    That doesn’t seem plausible to Tim and it doesn’t to me either. At least not if we are able to “fix” (not that there’s anything wrong with it) AtomPub in its current state, which I am highly confident that we’re able to do. So please, could you or someone on your group, someone who knows the WordPress API or any other proprietary API send an e-mail to the AtomPub mailing list so we can ignite the discussion around this?

    In advance: thank you ever so much.

  7. James Snell and I have been talking about this since we first met last April. I think there is every intention of making a blogging “profile” or Best Current Practices doc. The Features draft could be considered a first step in that direction as a lot of the other features that are missing are trivially added once the process of discovering those features is standardized.


  1. 1 WLW+AtomPub: Introduction « whateverblog.
  2. 2 It Pays To Advertise « turnings
  3. 3 Finance
  4. 4 WLW+AtomPub, Part 3: Picking Collections « whateverblog.

%d bloggers like this: