So what does this really mean?
From the point of view of WordPress and this plugin there are three main additions:
- Adds the <cloud> element to your RSS2 feed (more details here and here) which tells clients where and how to sign up for notification requests.
- Registers a URL handler with WordPress to process the notification signups.
- Sends out notification updates when a new post is published.
The cloud element looks like this:
<cloud domain=’josephscott.org’ port=’80’ path=’/?rsscloud=notify’
registerProcedure=” protocol=’http-post’ />
The domain, port and path attributes combined to form a URL, http://josephscott.org:80/?rsscloud=notify in this case, where others sign up for notifications. The registerProcedure attribute is the XML-RPC method to be called if the protocol attribute was xmlrpc. Since the plugin uses http-post for the protocol the registerProcedure field is blank.
Using this same example here is a small chunk of PHP code that uses the cURL library to sign up for notifications:
$curl = curl_init();
curl_setopt($curl, CURLOPT_URL, ‘http://josephscott.org/?rsscloud=notify’ );
curl_setopt($curl, CURLOPT_POSTFIELDS, ‘notifyProcedure=&protocol=http-post&port=80&path=/~joseph/rsscloud/&url1=http://josephscott.org/feed/’ );
curl_setopt($curl, CURLOPT_VERBOSE, 1);
curl_setopt($curl, CURLOPT_POST, 1);
curl_exec( $curl );
print_r( curl_getinfo( $curl ) );
curl_close( $curl );
This code sends an HTTP POST request to http://josephscott.org/?rsscloud=notify asking to get a notification when the http://josephscott.org/feed/ feed is updated. The notification is to be sent to the remote IP used in the request (this means notification requests must be sent from the IP that will be receiving the notifications), port 80 with a path of /~joseph/rsscloud/ and it will be given the update data via an HTTP POST. The notification script will get $_POST data that looks like:
[url] => http://josephscott.org/feed/
It is then up to notification script to turn around fetch the updated feed.
How fast does all this happen?
It depends 🙂
On WordPress.com the notifications happen through the jobs system, which means it will be sent out very, very quickly. On a WordPress.org powered blog with the plugin it schedules notifications to get sent out as soon as possible with the wp_schedule_single_event( ) function. Scheduled events in WordPress are checked on each page load, so if you publish a new post and then view it on the front page of your blog the notifications will get sent out in pretty quick.
I think for most blogs these approaches will work fine and send out notifications with very little delay.
What does this mean for feed readers like Bloglines, Google Reader, etc.?
I believe that many (most?) public feed readers like Bloglines and Google Reader already listen for feed updates via pings (like those sent to Ping-O-Matic). With an RSSCloud enabled WordPress blog they can register for updates to specific feeds. Why would they do this if they are already getting ping updates? Unfortunately the ping updates are similar to email, they have massive amounts of spam in them. Since RSSCloud isn’t a stream of everything, but a specific request for specific updates they could sign up for updates to those feeds that they believe are more likely to be legitimate.
Signing up is simple for a feed reader (or anyone/thing) to do:
- Look for the <cloud> element in the RSS feed
- Sign up for notifications using the data from the <cloud> element
- Process notification that are sent to it from WordPress
If you are working on RSSCloud support in your feed reader let me know, I’ll be watching the RSSCloud stats on WordPress.com. And of course if you run into problems with RSSCloud on a WordPress blog (ORG or COM) I’m happy to help track down any bugs in our implementation.