On Feeds and Backwards Compatibility

Zach Hale notes:

Should I choose RSS or Atom?

Who cares? I don’t. I bet if I asked everyone I had contact info for, only a few would prefer one or the other (though hopefully one in particular).

I've got a preference — Atom. This is mostly because of the fact that's it's one de jure standard, as opposed to the at least five de facto RSS standards.

More to the point, I agree with the underlying argument:

And that being so, it makes no sense to put both standards (if not different versions of each) in the auto-discovery tags, especially for big sites like Flickr and consumer blogging software like WordPress. [...] For the rest of us, our feed readers could care less. So please stop confusing us.

Sadly, I also know the history behind this. Back in the "bad old days", feed readers did not follow the robustness principle. So, websites had to deploy a sort of "inverse robustness principle", to make sure that as many feed consumers as possible could read the content. The good news is that today, any decent feed reader can read most feed formats. The bad news is that no one (or not enough people) have bugged the feed producers (e.g., Flickr) into fixing it. The solution? File a bug and remind them of Postel's law. Of course, only file said bug if no one else has already done so — we don't need to annoy the developers.

Re: Atom Protocol Exerciser (Ape) setup notes

Note: I had intended to post the first part of this on his blogDave Johnson's blog as a comment, but it rejected me twice. Apparently I write like a spammer.

That was a lot more complicated that I had expected; makes me wonder if I'm the first person (other than Tim, of course) to deploy the APE.

I deployed it locally a few months ago, while debugging my Atom protocol plugin for Trac. During that time, I wrote up some implementation questions (which Tim graciously answered) and the method I used to run it.

---

Incidentally, lately I was tweaking my particular implementation since Tim Bray had recently updated the APE to be compliant with the latest revision of the specification. My shebang line for go.rb changed from #!/bin/bash /usr/bin/jruby to #!/usr/bin/env jruby. It's still working fine, even if it's still a little slow.

I need to figure out how to fix some of the errors that I get. For instance:

18. ? Client-provided slug 'ape-61911' not used in server-generated URI.

I have no idea how to fix this. When I get a valid Slug header, I use it verbatim:

To server:

GET /trac/atom/wiki/ape-61911 HTTP/1.1\r
Host: localhost\r
Accept: */*\r
\r

Perhaps the following line is confusing the APE:

Location: http://me.malept.com/trac/xmingw/atom/wiki/ape-61911\r

Additionally, apparently my plugin currently has some problems with the new multi-post app:edited test, but so far I think it's something wrong in my code as opposed to being a bug in the APE. I'm going to try to take a look at it tonight.

Ego++

Typically, I'm not one to toot my own horn too much, but I'm rather excited about this. Because of my earlier post, two things happened:

1. The APE was changed to support HTTP status 204 No Content, and
2. the APP draft specification was changed to clarify (via text and examples) that non-200 OK responses for PUT/DELETE were acceptable.

I think it's awesome that I could (somewhat indirectly) influence a standard like that. At the very least, it gives the ol' ego a little boost.

trac-atompp progress; APE questions

I'm working on (among other things) finishing up wiki support in my trac-atompp plugin. I'm nearly done, I think. In order to make sure it's "valid", I'm using Tim Bray's APE (albeit from CVS). However, I've got a few questions about some of the errors:

8. ! 53 of 53 entries in Page 1 of Entry collection lack app:date elements.

From the source, it looks like it should actually say app:edited. But, why is it giving an error? According to draft 14, section 10.2, Atom Entry elements in Collection documents SHOULD contain one "app:edited" element, and MUST NOT contain more than one. Perhaps the messages should conform to RFC 2119 instead of lumping in all of the SHOULDs with the MUSTs, or something.

49. ? Can't update new entry with PUT: No Content [Dialog]
50. ! Couldn't delete the entry that was posted: No Content [Dialog]

I don't really understand why HTTP status code 204 (No Content) isn't allowed for either PUT or DELETE, seeing as RFC 2616 says that it is a perfectly valid response for both actions.

Trac-AtomPP progress, 2007-01-23

I finally got myself out of my Trac plugin coding slump. Genshi is really making this a whole lot easier; I don't really know why I was manually generating XML from trees in the first place.

I am very grateful for the existence of Joe Gregorio's Atom Publishing Protocol test suite. There are only a couple of nits about it — first, it doesn't seem to play well with Multi-version installs of wxPython (seems to require 2.6, perhaps 2.5 [I only have 2.4 and 2.6 on my computer]), so I cooked up a really simple patch for that. Secondly, my wiki collection feed generates some warnings via Feed Validator, but in the logging pane, it records them as errors. Since it doesn't affect the functionality, I merely consider that a minor usability bug. But, this really doesn't seem to be meant for end users, so...whatever.

Anyway, for my capstone, I'm only working on the wiki part. GET is done, and POST is nearly done. DELETE is done in theory (haven't tested it out yet), and PUT still needs to be converted. POST and PUT now require some implementation of ElementTree to be installed, in order to parse the Atom Entry input. As an aside, ElementTree's find*() methods are really poor substitutes for XPath. Also, this implementation utilizes the Atom MIME type parameter draft whenever possible.

Reminder: Bazaar URL is: http://bzr.malept.com/trac-atompp