I’ve written up some thoughts on that regard on my blog today:

http://workbench.cadenhead.org/news/3559

Also, there’s an old list of implementations (both client and server) here:
http://wyman.us/main/2004/09/implementations.html

I actually expected support to be higher than that (and perhaps these days it is), because for a client, supporting RFC3229+feed is dead simple – like your cat walking over the keyboard and accidentally implementing it (assuming you already support etags/last-modified).

And Rogers, I’m surprised you had no idea, considering RFC3229 was at one point on the todo list for the RSS BPP. I kind of thought it was common knowledge for RSS geeks.

Back on the subject of RSS cloud – like Dave, I think of it as a neat optimization, rather than a vital component. However, for people for whom real-time communication is critical, I can see how RSS cloud would not be adequate.

Still, I’m keen to play with it when I have some spare time. I know it’s pointless, considering I typically read feed articles hours, if not days, after they’ve been published, but semi-real-time updates would just be cool in a geeky kind of way.

They do? Where? Where? I had no idea.

Thanks for the clarifications re: ETags/headers. I did a little hand-waving on that part, and I appreciate the nitpick.

And thanks as well for bringing up RFC 3229. I haven’t seen much lately on RSS reader support for that spec. Anyone know of a reasonably current survey?

Your point on the practicality of long-polling/streaming is well-taken : it isn’t practical to do that with a large number of feed providers. Just like Apple’s Push Notification Service, this is really only practical with a centralized service provider. FeedBurner and Pingomatic both filled similar niches… highly-available and centralized services.

There is a trade-off between having decentralized service endpoints with degraded reliability VS a centralized service endpoint and higher reliability.

It’s important to note that Dave Winer doesn’t want the centralization, and doesn’t sound concerned about reliability. He writes: “I designed this to be decentralized … I’m not risking anything, because we know that polling works for RSS. rssCloud is an optimization, its purpose is to make RSS faster. But if it fails RSS still works.”

If rssCloud is really just intended to be an optional “nice if it works, oh well if it doesn’t” feature, then the implementation details probably don’t matter that much. It will be interesting to see how/if it catches on… my experience is that users get pretty upset when they come to rely on something that starts to degrade in performance. Maybe it will take some initial successes before the pain drives rssCloud to evolve.

As for some of the other criticisms of RSS cloud that have been raised:

Firewalls aren’t necessarily a show-stopper. Many modern routers include support for UPnP which enables a client to open up ports on the firewall as needed. So while this may limit the potential users of RSS cloud on the deskop, it’s not like everyone behind a firewall is screwed.

Clients don’t have to fetch the full feed when they receive an update notification. Many feed readers have had support for partial feed updates via RFC 3229 for years now. If necessary a server could limit its cloud access to only those clients that supported partial feeds.

As for long-polling and streaming, I don’t believe those techniques are practical when you have lots of feeds. There is an upper limit to how many TCP connections you can keep open at once, and even if you don’t hit that limit, it’s wasteful keeping a bunch of connections idling.

Now if you had a tiered system, where you connected to a small number of hubs that in turn connected to your hundreds of feeds, a permanent connection makes more sense. I’m assuming Google’s PSHB works something like that. However, there need to be a large number of hubs to make this kind of thing palatable, otherwise it’s just another centralised point-of-failure.

I don’t think RSS cloud is without its problems, but I’m not yet convinced that it’s completely unworkable. As a client developer, the only reason I never considered implementing it in the past was because there was no significant server support. With WordPress backing, though, I would think it’s at least worth a look now.

Regards
James

Currently a webserver handing out static XML files can serve RSS. It doesn’t need any special knowledge, storage, etc. for the clients.

With this proposal, and all pub/sub things, the clients subscribe at the server, so now the server needs to remember subscribed clients, and for each of them potentially the list of things they haven’t seen yet (this is probably why rssCloud apparently avoids partial updates – they are too heavy for the server). And the server has to remember which clients seems to be dead, queue up changes for slow clients, etc.

The individual storage needed for one client is certainly not much, but if you have a popular page with 100’000s of subscribers, it’s going to kill you, while handing out a static file with conditional GETs (I think no one uses HEAD for that) is at least possible, and can be easily supported by proxies etc.

I think pub/sub will only make sense in certain EAI scenarios where you have a very limited number of clients, and they all have the resources and technical skill to set up web servers.

Wouldn’t it be preferable to pass the new item to the client instead of sending a notification to trigger RSS polling?

Absolutely. Sending delta updates would be a better use of the notification because it cuts the communications overhead in half… the new content is the notification.

Along those lines, it is easy to think up an RSS server API that would facilitate “PartialRSS” feeds which only include what you want. For example:

The entire feed: http://somehost/somefeed
Only items since a given time: http://somehost/somefeed?since=09082009,1300
Only the items before a given time: http://somehost/somefeed?before=09082009,1300
Only the most recent item: http://somehost/somefeed?limit=1

And so on. A server with this kind of flexibility could then more easily support notifications that pushed out the newest items to clients.

I had mulled over the HTML 5 Web Sockets API when writing this post, but decided I was being long-winded enough without bringing it up. While I think the concept is pretty cool, I’m not sure it’s a good fit for RSS. My primary hesitation is that it brings in a whole dependency chain on HTML 5 and DOM handling. That’s a heavy stack on top of “plain old XML”.

As for “fragmented feeds”, I’ve been kicking around the term “PartialRSS” lately. As Rogers has commented, the best scenario for push notifications would be to actually push the deltas (new items) rather than just a “something changed” message.

I’ll let you expand on the rest of your own vagaries. Lets hear it!

let me throw some vague stuff out there and i’d like to hear your thoughts.

html5 web sockets

html5 offline apps and/or google gears

webapps (wrapped in mozilla prism, fluid or other app wrappers for single-site-apps)

p2p / client / server apps – transfer rss sub status log file that lists all feeds that have been updated (since last transfer) and client pulls down those feeds or only those new feed items (fragmented feeds).

webhooks

just random thoughts. maybe you can ellaborate for me

I had read through Dave’s site, and was admittedly a bit lost on why “real time RSS” is considered so important. After reading your article, I’m not entirely sure I see the benefits above and beyond what is presently defined – but neither am I the most educated in this area of expertise.

So with that said, I felt your parallel to SMTP handling (of which I know a bit more about) to be very useful and on-point as I attempted to discern client vs. server calls. Overall, I have to say I don’t really understand why we would need to adopt a push mechanism for this type of technology given as it would seem to begin to mirror other protocols already in place – so why not leverage those in a conjunctive fashion (again, without understanding the full technical scope).

In summary, I agree with your assertions because I usually attempt to balance my background within business network administration, project management, and line of business focus to draw conclusions as to whether and how technology can be leveraged to complete a given business objective.

That’s where the rubber leaves the road for me, as I’m hard pressed to see how the energy exerted to move to a new standard supersedes the blossoming adoption of a technology which still seems mysterious to many out there.

Your thoughts are appreciated, and thank you for taking some time to outline this. I welcome your feedback and assistance in helping me understand if I might be missing something that could shift the perspective.

Warmest Regards,
K

There’s another that I wonder about. If clouds make Twitter-style services possible over RSS, that means people posting dozens of short messages a day.

Under RSSCloud, each one will trigger a request of the full RSS feed.

That’s a lot of bandwidth just to get one short update after each notification. Wouldn’t it be preferable to pass the new item to the client instead of sending a notification to trigger RSS polling?