Last update: Sun, Jul 29, 2012 at 12:13 PM.
rssCloud home
    • In the early days of RSS, we had the idea that instantaneous updates would be the next step.
    • That was 2001. It took a little longer than we thought, but now with "realtime" as the Next Big Thing, it's time to reboot all that stuff.
    • This is where I'll document my efforts.
    • For news and developments, watch blog.rsscloud.co.
    • To participate in the community, join the rss-cloud mail list.
    • Dave Winer
      July 2009
    • There are three sides to the cloud:
    • 1. The authoring tool. I edit and update a feed. It contains a <cloud> element that says how a subscriber should request to notification of updates.
    • 2. The cloud. It is notified of an update, and then in turn notifies all subscribers.
    • 3. The subscriber. A feed reader, aggregator, whatever -- that subscribes to feeds that may or may not be part of a cloud.
    • As of July 25, 2009, I have a cloud operating.
    • It's described in the Implementor's Guide document.
    • Here's the log of the server. It shows all notification requests, pings, file saves and notifications.
    • Two sample files: 1. My personal notes and 2. A test feed that updates every 15 minutes. I suggest doing a View Source on these files to see how they connect to the cloud.
    • The source for rssCloud.root, an OPML Editor-based cloud server.
    • My River2 aggregator, which receives instant updates from cloud-enabled feeds.
    • My LifeLiner authoring tool, still in development.
    • For news and developments, watch blog.rsscloud.co.
    • The first rssClouds were implemented in 2001 in Manila and Radio UserLand, two products from my company, UserLand Software. All three sides of the protocol were implemented.
    • In 2002, we spun out the server side into an open source release called Radio Community Server, which had other functions that supported communities of Radio users. We operated two such communities, one for our own users, and one in partnership with Salon. A bunch of leading weblogs came out of these services.
    • The aggregator in Radio UserLand would receive instant updates of feeds of other members of these communities, but not many people noticed. We also had the equivalent of Twitter's "retweet" (that's why the <source> element was added, so the feed would link back to the originator, a feature that Twitter doesn't have).
    • In any case, polling became the norm, and the cloud functionality didn't get much use outside of our communities.
    • You bet!
    • Just define a namespace to have a single element in it, the <cloud> element from RSS 2.0.
    • If you need a URL for the namespace, please consider using the URL for this site.
    • Namespaces make ideas portable, and not specific to any format, and don't lock anyone in or out. :-)
    • 7/15/09; 9:25:11 AM by DW.
    • Per Daniel Berlinger's question in the comments below, there is a REST interface coming out of the rssCloud interface. It's mentioned both in the RSS 2.0 spec and in SOAP Meets RSS.
    • However two details are not included in the description, so I've had to fill them in, in my implementation of rssCloud.
    • 0. The method is (of course) POST.
    • 1. It takes a single parameter named url, whose value is the address of the feed that updated. (The spec didn't provide the name of the parameter.)
    • 2. The returned value is ignored, as with the returned value of the XML-RPC and SOAP notifications. (The spec didn't explicitly say the returned parameter is ignored.)
    • I've got a sample handler running at: http://rpc.rsscloud.co:5337/rsscloud/postUpdate. If you call it as described above it returns Thanks for the post.
        • This is the second time I've implemented it, the original implementation is still here in xml.aggregator. Using that code to guide me.
        • New pref, flRequestCloudNotify, if true we do the whole dance and get realtime updates. Only set true if you're not behind a firewall thought.
        • Stats for tracking real-time updates.
        • Init stats.whenLastCloudRenew.
        • New routine. Every 24 hours it resubs to feeds that have cloud elements.
        • One handler, feedUpdated, receives notification that a feed changed.
        • Implement a new sub-table of feedInfo table for each feed, cloud. It's present only if the feed has a cloud element.
      • Respect the "enabled" boolean everywhere relevant.
      • Timestamp subscriptions and delete after 25 hours.
      • Make log available as a Javascript include, so people can view the log from this site.
      • Log new subscriptions.
      • Add support for http-post protocol for notification, in addition to xml-rpc and soap.
      • Use identi.ca username/password for saving RSS feeds through storage system.
    • Yes! In a sense that's the whole point of this exercise. It'll be a feed that you can get updates to in real-time because it will be hooked into the RSS cloud.