Long in the Horn and in the Tooth

Nick Bradbury recently posted an essay about Microsoft's proposed support and extension of RSS to ship in Longhorn.

In it, he says the following about Microsoft's plans:

Now, Microsoft plans to add a common RSS feed list and feed store to Longhorn, which means that instead of requesting feeds via HTTP, aggregators like FeedDemon would request them through Longhorn's RSS APIs - enabling Windows to find out what you're paying attention to. That sounds incredibly useful for developing personalized search, doesn't it?

I don't agree that using a Windows API function call instead of a straight HTTP request is a win for RSS overall. One of the benefits of RSS is that the common denominator -- or default, if you will -- of how to get RSS-formatted data is via the existing web infrastructure. Which is to say: HTTP. Attempts to "embrace and extend" RSS are one thing, but to provide that extended RSS only through a closed API is a low percentage move for an open and interoperable web ecosystem.

Which isn't to say that Longhorn is going to stop people from making HTTP requests to get their feeds. I doubt many people (relative to the size of the entire feed publishing universe) will design their feeds to take advantage of Longhorn specific features, and so Microsoft may end up using their new feed API as an obvious way to give the user back a feed which has the new bells and whistles their extended RSS format will support. Obviously this is conjecture, but more than the idea of modifying or extending RSS, the API shift bugs me.

The last thing RSS seems to need is more versions and divergent feature sets (aren't the nine or thirteen or however many we have enough already?), but at least I've been able to rely, generally, on HTTP by default as a way to get that data.

(I'm not against RSS in other transports, like say SMTP, but that's also a well-documented and implemented protocol, and not a proprietary API).