Rather than brave the turbulent waters of altering the RSS specifications or try to change the direction of the emerging Atom specification, either of which is likely to be an exercise in futility, and perhaps not even desirable, I'm considering coming up with yet another content syndication specification. Foolhardy? Maybe. Will any tools support it?...
[read more]

I had a few more thoughts on the Cloud interface that appeared in the RSS 2.0 spec, so I'll lump them together in this post.

* First, I just checked the spec, and it doesn't state that subscriptions expire every 25 hours, but another document (which the spec links to) does state that "by convention",...
[read more]

Here's a question--could the Atom API be packaged as an extension to RSS? I'd have to read the spec to see where the mismatches might be, but I would think that at least a subset of the API could be made to work with RSS. That way, a site that has standardized on RSS as...
[read more]

Another way to reduce the size of a newsfeed in cases where more than one element often contains the same data would be to introduce the concept of element aliasing or defaults. For example, if the guid is almost always (or always, or even just often) the same as the link, then the feed could...
[read more]

Continuing further on the idea of lightening the RSS load by allowing the client to request a subset of the elements contained in a newsfeed, here are a few more thoughts:

First, to reduce processing requirements on the server, rather than dynamically generating the feed based on the elements requested, the server could keep a...
[read more]

One thing I've wondered about Atom--why doesn't it use the same names as RSS for elements with the same purpose? For example, why call entries "entry" rather than "item"?

I know Atom is not RSS, and isn't pretending to be. I know Atom wouldn't be "backwards-compatible" with RSS even if some elements had the same...
[read more]

Continuing with the ideas of allowing the client to request only a subset of the elements contained in each item in the feed, and of allowing the client to request only new and/or updated items, the next idea is to allow the client to request one set of elements from new and/or updated items, and...
[read more]

I'll begin by echoing a suggestion that has been made elsewhere before: RSS needs a mechanism to request only items that are new or updated since a particular time. Now to expand on the idea and some of the issues it brings up...

First, in case this hasn't been mentioned before, it would be good...
[read more]

One of the big challenges facing RSS as is grows is the need to ensure that, with increasing numbers of subscribers, bandwidth requirements don't balloon out of control. RSS 2.0 begins to address this with the cloud subscription interface. Many opportunities remain for extending cloud or creating an API that could plug in to RSS...
[read more]

One thing that didn't catch my fancy in the Atom spec was the number of required elements for an Atom feed. For example, each entry (like an RSS item) in an Atom feed must contain both a "modified" date/time and an "issued" date/time. It may also contain a "created" date/time. If there is no "created",...
[read more]