RSS Support Design Notes
by Andrew Grumet , Jerry Asher and Dave BauerFrom the specification,
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)
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 runrss_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
Note: we assume that/${RssGenOutputDirectory}/${ImplementationName}/${summary_context_id}/rss.xml
${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.
aegrumet@alum.mit.edu, jerry@theashergroup.com, dave@thedesignexperience.org