| Home
XML
RSS
OPML
XML-RPC
SOAP
|
|
 |
|
RSS 0.92
Posted by Dave Winer, 12/25/00 at 5:31:21 AM.
Philosophy 
RSS is a Web content syndication format.
How 0.92 relates to 0.91
0.92 is upward-compatible with 0.91. Every new feature of 0.92 is optional, meaning that a 0.91 file is also a valid 0.92 file.
Changes in RSS 0.92
1. In 0.91, the <language> element is required. In 0.92 it is optional. If a channel is formed from various input sources there's no way to know which dialect of English it might be using, or if it might include text that's in Italian, German or Swedish. I faced a difficult choice, force the user to lie about the channels, or face the reality that sometimes we can't say what language a channel is written in.
2. A new optional sub-element of an <item>, called <source>. Its value is the name of the RSS channel that the item came from, if any. It has one required attribute, url, which links to the XMLization of the source. The purpose of this element is to propogate credit for links, to publicize the most-used sources of news items. (Comment: I want to see if there's some way the <source> element can become a chain, so if I get a link from a channel that got it from some other channel, that's included.)
}3. We want to use RSS to push largeish content around the Internet, therefore we contemplate adding an <enclosure> element to <item>s. Somehow it will include a content-type attribute and a pointer to the content. It would also be nice to know how large it is, so that the user-agent can prioritize the download. For background, see this essay about Adam Curry's "last yard" concept.
4. Hourly updating is fine, but some people want to know immediately when a channel has changed. That's the motivation for the new <cloud> sub-element of <channel>. It specifies a webapp that supports the rssCloud interface, described below, which can be implemented in either XML-RPC or SOAP. Its purpose is to allow processes to register with the cloud to be notified of updates to the channel. This will allow updates to be visible to readers moments after they occur. UserLand is developing such a cloud at data.ourfavoritesongs.com. A <cloud> has five required attributes: domain is the domain name or IP address of the cloud, port is the port that the cloud is running on, path is the location of the responder, registerProcedure is the name of the procedure to call in the cloud to request notification, protocol is either xml-rpc or soap, indicating which protocol is to be used.
rssCloud interface
This interface can be implemented in either SOAP or XML-RPC.
A workstation can register with the cloud to receive notices of changes to a channel by calling the procedure named in the <procedure> attribute of the <cloud> element. It takes five parameters: the name of the procedure that the cloud should call to notify the workstation of changes, the port the workstation is listening on, the path to its responder, a string indicating which protocol to use (as described in #4 above), and a list of urls of the RSS files that are to be watched. The cloud can determine the IP address of the caller from the request. A workstation cannot make a registration call on behalf of another. It returns true if it was able to do the registration, false otherwise.
The cloud calls back to the procedure named in the registration call with one parameter, the url of the channel that changed. At that point the workstation could read the channel, or notify other workstations that the channel has changed, clear a cache, or do nothing. The workstation returns true.
By convention registrations expire after 25 hours. Workstations should register every 24 hours for every subscription to keep them current.
Examples
I have a folder of examples. They are maintained by a new bit of desktop software coming from UserLand that makes it easy to route news items from RSS channels into new channels.
|
