RSS technology, the really final take – really

So this week will really be the final week of covering RSS.

So this week will really be the final week of covering RSS. For two weeks now, we have promised to wrap up this topic and, well, we failed. That said, we failed with panache, with moxie, with a certain je ne sais quoi – which is to say that we did as we pleased in an unabashed, unashamed and uninhibited sort of way.

Last week we concluded with JSMsg, a unique proposal for a standard that lets users who don’t have any kind of aggregator installed view feeds.

To recapitulate: In the words of the designer of JSMsg, John Repici of Creativyst Software: “JSMsg is not ‘yet another RSS flavor’. While RSS is designed to let individuals display news feeds on installed reader software, JSMsg is designed to let Web masters display news feeds directly on Web pages.”

Let us explain. When you run a Web site and you want to provide an RSS feed, you use some kind of script or application to generate the feed, which is just an XML file.

For clients to be able to do anything with the feed they must have an aggregator that takes the XML and reformats it into something that is humanly readable.

If you want to show the contents of a feed on your site you need to translate from XML to HTML. But there’s a penalty – to show human-readable content you need software and extra processing to either create and interpret the XML feed data, whether created on your site or someone else’s.

An even more-compelling reason to use JSMsg is that if you create feeds that you want to distribute widely, keep in mind that any site that can’t create HTML from RSS XML is not going to be able to use your feed – with JSMsg they can with next to no effort.

JSMsg also reduces the bandwidth demand on sites supplying JSMsg feeds. To quote Repici again: A “JSMsg feed can be a regularly updated static JavaScript file residing on the Web server so it works with existing Web caching schemes. It will be cached by browsers and intermediate cache mechanisms based on 304s (not-modified) statements from the server and other criteria. While it may also be dynamically generated, it operates completely within the existing HTTP framework.”

How does it work? Glad you asked. JSMsg simply stores the content of an RSS feed in a file nominally called JSMsg.js, though this is not mandatory. The content must be JavaScript compliant with Version 1.1 or lower.

And a crucial concept in this scheme is that JSMsg requires namespaces to be used so that content from multiple sources can be combined on a single Web page.

The actual JSMsg file contents must contain seven functions. These functions provide different displays of the JSMsg content, from showing everything to randomly selecting single items.

So, to use a JSMsg feed on your site, you need to use the following HTML code in the header section of your Web page:

And in HTML body you need to include:

.Msg(“Body”);

.Msg(“Attrib”);

In this example, the function Msg(msgPart[, Offset]) displays a part of a message from a short list of messages kept in the JavaScript file and selects which message is displayed from the list at random. The optional Offset parameter specifies a message number offset from the random number.

For all of the details of how to code a JSMsg file, click here.

But given that so few feeds exist in JSMsg format, what can you do if you are interested in the system? The answer is to use a translator. Creativyst provides such a beast through a free Perl script that translates RSS feeds into JSMsg feeds.

This script can be run in a Web page to dynamically create a JSMsg JavaScript on the fly, or it can be run as a scheduled cron job (or whatever your server uses) as frequently as needed to update static JavaScript files.