What is the logic behind sunsetting RSS feeds moving forward?
We think feeds in general are important. Its still early in terms of feeds—for most users even knowing what theyre for—and what were aiming to do is make it as easy as possible for them. We felt the easiest and best user experience would be to say "do you want a site feed, yes or no?" and in order to do that we picked a feed format that we thought had the most potential going forward and, importantly, was linked with the API that we support.
Thats one of the beauties of ATOM that gets overlooked; its the same format for the API as for the feed. If there are a lot of these feeds out there, we think it will be easier to develop toward it, and the extensibility of ATOM will take out a lot of support and potential confusion for our users.
Theres also the fact that for those who care—a lot of them are old Pro users who still have that option—there are other services like Feedburner for instance, which will translate and give you RSS for your ATOM feed if thats what you want. There are always options available for the more sophisticated users who want to get into that.
Could Feedburner be a service thats transparent to the user? You have to go off to another site, and do what with it? How does that work?
Feedburner, yes, the user would have to do something there. But it seems the users who care about that type of thing are exactly the users who can handle going off and doing that. The majority says site feeds, great, and to present them with the options would not necessarily be that helpful.
Since youve got your API and the ATOM API support, couldnt you or a third party develop or build a bridge that would handle these transforms for the users with older readers that dont support ATOM, particularly since its not even fully completed?
Sure, thats something we could do, and have looked at doing and will continue to look at. Its just like anything—the costs versus the benefits for users—and what seems to be important for them hasnt weighed out too favorably for that yet. But we think its important to a lot of people; well definitely look at it.
From a pragmatic perspective rather than a political one, if youve got the ability to e-mail into the system and e-mail out of it, you have the ability to send this data to a third party who could do a transform and make the whole issue go away.
Potentially, but we try to separate the political issues from whats best for our users as well. There are tons of things we can do that seem easy and worthwhile, and every day were weighing those against each other. We have things like comments and profiles that we think are going to make a much bigger difference to the majority of our users than the format of their feeds. So in the next round of stuff, maybe well be able to look at that.
What about work going on in the RSS space, such as enclosures for example?
Its another thing we might look at. Right now most of our users dont have the ability to upload large files, so Im not sure if a lot of them would be able to take advantage of that. Im interested in enclosures—I havent actually played with them much myself.
Theres the peer-to-peer work as well, technologies such as BitTorrent to spread that load. Since ATOM ostensibly encompasses most if not all of the capabilities of the RSS format, there should be no reason why that kind of functionality couldnt migrate as well?
I agree. Theres a lot of work to be done there, and were hoping to keep on top of it.