Yesterday, I had the RSS Weekly webcast running in the background as I worked. Since I was only listening with half an ear, I probably got the wrong impression, but one of the guests or callers sounded like they were trying to shoehorn data into RSS that just didn't belong there. How far should a technology like RSS be stretched to accommodate various communications needs, and when is it time to create a new format?

Since I don't remember what the usage was that sparked this blog entry, I'll make up an example of something that I can imagine someone doing, which in my opinion really would not fit into RSS: online gaming. Imagine a multi-player online game that passes data around in RSS format. Each <item> has a command name in its <title> and some data to go along with it in its <description>, either in some text format, or base64 encoded. Each client polls the server as quickly as it can process the data and off you go.

Absurd.

The overhead of all the XML processing would be entirely unnecessary, the data is not well matched to the meaning of the RSS elements, and the high-speed polling is entirely abnormal for RSS. Could it be done? Sure. By why? Oddly enough, things like this get done from time to time. For some people, it's a matter of wanting to ride the latest buzzword. For others, it actually seems like a good idea ("Look at this cool new use I found for the RSS format! It's the greatest, most flexible format ever! And I'm a pioneer, pushing the boundaries of what it can be used for!").

So where to draw the line?

First, anything that requires high-speed polling should probably use a high-speed format--in other words, a format that doesn't require any kind of complex encoding or decoding, and which doesn't carry a lot of extra baggage. XML is great for a lot of things, but with all the start and end element tags, XML files end up being a fair bit larger than the data they carry. In the above example, if binary data has to be base64 encoded, that also adds processing overhead that is not appropriate for a high-speed polling application.

Second, if and XML format is appropriate, but the data types being transmitted don't have more than an very weak correlation to the elements in RSS, you may as well build another XML format. The next point goes into this more.

Third, if your data isn't meant to be consumed by a feed reader, or is not closely related to data that is destined for feed readers, that's a hint that there may be no point using a format built for feed readers.

Point #2 above is probably more important than point #3. I once posted an entry in this blog discussing the possibility of using RSS or Atom to deliver software updates. I stand by that idea, because I can see a reasonable correlation between RSS/Atom fields and the data that would be required for a software update (title = software title, link = link to the binary data, data = version number perhaps?) One could certainly subscribe to such a feed in a feed reader, even though it was intended for automated update systems.

On the other hand, maybe I am just another buzzwordist trying to ride the RSS wave.