RSS Support Design Notes

by Andrew Grumet, Jerry Asher and Dave Bauer

RDF Site Summary (RSS) is a lightweight multipurpose extensible metadata description and syndication format. RSS is an XML application, conforms to the W3C's RDF Specification and is extensible via XML-namespace and/or RDF based modularization.

This service package provides low-level support for generating and parsing RSS feeds.

1. Feed generation

Feed generation is the process of summarizing local content as RSS xml. To generate a feed we need to know

the site context whose content is to be summarized,
how to retrieve the various required and optional metadata fields
whether any changes have been made since the last summary was built
how often to rebuild the summary (if changes are present)

The last item is included with an eye toward performance. In the event that a particular summary is expensive to produce, we may opt to rebuild at most every N minutes (or hours, or days).

Usage scenarios

Publisher wishes to syndicate the Bar Forum in the Foo Bboard package instance.
Luckily, the bboard package implements the summary service contract for individual forums.
Programmer registers the context identifier for the Bar Forum with the summary service, indicating that the summary should be built no more than once per hour.
Summary is available at /some/url/specific/to/bar/forum/summary.xml

Service contract

The feed generation service contract is called RssGenerationSubscriber and consists of two operations.

Datasource(summary_context_id) returns a data structure that contains all required metadata fields plus configuration information such as the RSS version to be used (0.91 or 1.00 are supported at present). This data structure contains everything needed to run rss_gen.
LastUpdated(summary_context_id) returns a timestamp that is used to determine if the live summary is out of date. The timestamp is given as the number of seconds since midnight on January 1, 1970, i.e. Unix time.

Under the hood

RSS files.All summaries are static files. They are served from a static directory under the webroot specific by the RssGenOutputDirectory, which defaults to rss. The full path to an RSS file is given by

/${RssGenOutputDirectory}/${ImplementationName}/${summary_context_id}/rss.xml

Note: we assume that ${ImplementationName} and ${summary_context_id} contain OS- and URL-friendly characters.

Subscription. A programmer registers a context with the summary service through API functions (we can make it possible through web UI as well if that makes sense).

Summary context. A summary context is a content-containing domain which implements the summary service contract. A summary context is not identical to a package instance. For example, a single bboard package instance might contain 3 summary contexts, one for each of the forums in the instance. The summary context must, however, be an acs_object for permissioning purposes (create a shell acs_object if necessary). Only one subscription is allowed per summary context.

Service. A scheduled proc runs through all subscribed contexts, checking to see if the live summary is stale and also if the minimum "quiet time" has elapsed. If the conditions for rebuild are met for a context, the scheduled proc pulls out the context's summary data via Datasource and uses the information to build a new summary page. This generic and simple scheme can be used to dispatch different versions of the summary builder as well as to support extensibility via modules. Warning: This design expects the output of Datasource to be reasonably small, as we will have to parse this list-of-lists to generate a summary.

2. Feed Parsing

(aeg's vague ideas: needs can vary. I can imagine slurping the content into the db or converting to includable ADPs using XSLT. Service contract operations are used to generate mappings to RDBMS tables or stylesheets.

aegrumet@alum.mit.edu, jerry@theashergroup.com, dave@thedesignexperience.org