Subscribe to
NSLog(); Header Image

Atom vs. RSS

Okay, so I've been looking at Atom support for this blog and whatnot, and there are a few things I can't figure out. I've looked at this page and a few others, and talked with Andy as well.

Atom has a range where you can say "give me articles 734 through 800" or "give me all articles from 892 onward" or whatnot. That sounds great, because if I write article 893, an RSS reader would only have to grab one article from my atom feed as opposed to the 15 I list in my RSS feeds.

But what about article 887, which I modified to add a postscript and to fix a typo? That'd be ignored, would it not?

Plus, with 1500 entries, is my Atom file going to be 1500 entries long? I'm not sure I understand how that works, on the client side or the server side.

I'm hoping that someone can provide a good answer to these questions.

P.S. I've implemented the default MT template here but all that's done is raise more questions. How is search (i.e. ?atom-recent=15 or ?atom-start-range=892) going to work? I dunno.

5 Responses to "Atom vs. RSS"

  1. Atom is a single name for two things. One is a protocol to replace metaWeblog and one is a file to replace RSS. That page is the documentation for the protocol API. Your file will be just like an RSS file, just more complex, larger, and with more unused data.

    That's progress! Yay! 😐

  2. the good thing about XML is that you can just ignore tags you don't need or aren't using (as long as the specs allow it).

  3. Adam, nice FUD. My ATOM feed is only 4k larger than my RSS feed. ATOM SUCKS HARD I GUESS.

  4. Only 4k? Multiply that a few thousand times and see if "only" applies. Then start counting days at that rate. It's not FUD. Format #1 performs task X just as well as format #2 yet format #2 is larger than #1. Which do you choose?

    Then add that format #1 is wide-spread and well-known and format #2 is being spearheaded by a fellow with a very public distaste for the creator of format #1 and -drumroll- you have useless technology.

    The Atom API, however, is a nice change. The file format is not needed.

  5. Clearly the Atom working group has screwed the pooch on this one. What was once a very romantic notion of unified document representation and content management across the web, has turned into a mess. It's not orthoginal, consistent or even remotely more attractive than RSS.

    Too bad, it had promise...