DNN Syndication Pamphlet

This document aims to start discussion on an improved syndication architecture for DotNetNuke. There are various developments relating to syndication that warrant a critical examination, and a possible overhaul of the current syndication architecture.

Syndication is the mechanism whereby web-based content can be distributed and consumed using standard protocols (e.g. RSS). This permits boundaries between applications (modules) and even websites to be crossed. In DNN the production of content is in the modules. The content can be handed off using an rss feed to a XML/XSL module like the Newsfeeds module which renders the content on another page of the portal. The latter is where consumption of the feed takes place and is the end of the syndicated flow.

This is the simplest of scenarios where a user wishes to display the syndicated content of one module on another page. For example: displaying the latest blog entries from a blog module somewhere on your site on your home page.

Combining multiple feeds from within your portal. Example: showing all syndicated content from a portal page (containing multiple modules) on the home page.

Showing content from another website on your portal. Example: use the BBCNews RSS feed to display the latest headlines on your home page.

Showing an aggregation of feeds from both internal and external sources. Example: combine a company internal blog on expertise X with an external news feed on the same subject.

The news module can be used to provide (definitions and renderings of) intersections and end points of syndication in the framework. Most of the logic will reside in the framework syndication API. The module will aggregate and offer its own feed to others (both internal and external). This way it will be possible to truly set up your own ‘wiring’ to route information through your portal.

Currently syndication is implemented as a by-product of ISearcheable. The module supplies new content on scheduled times to the search engine and it is assumed that this can be used as a basis for syndication.

Simple to implement as the module developer does not need to do anything more than implement the search interface.

No/little control over syndication by module developer. The SearchItem is the vehicle of transmission which was designed for searching, not syndication.

Initiative lies with the framework to retrieve content which it will do at scheduled times. It is questionable if this is adequate for content syndication.

The latest release of the News module is a simplified XSL transformation module. It takes as input a RSS feed and uses XSL to render this on screen.

·         No caching. This means that on every page hit the RSS feed is retrieved again. When using external sources this can lead to timeouts and ugly error messages.

·         No aggregation. It is important that we can display an feed from multiple sources.

·         Limited in rendering options. Xslt is very powerful, but it would be more user friendly to have more mechanisms such as templating to render content.

A module optionally implements a syndication interface. The framework can ask for a feed and the module developer can use a designated class for this. This class must be designed to handle possible extensions to syndication such as SSE.

The module should be permitted to define any number of feeds. The feed request should be parameterized for this.

The framework must provide an API that deals with syndication (this is already underway). The API should:

1.       Provide a unified code base for both production and consumption of feeds

2.       Take care of caching . Ideally the caching should be made to rely on a simple cache dependency like an IsDirty Boolean on the part of the module. I.e. the module can flag that it has new content and the framework will request a feed again when necessary if this flag is set.

3.       Do aggregation. It should also understand that asking for a feed from a page means aggregating the modules on it. One could imagine that you have a skin object that points to this mechanism so you have a feed button on every page that gives a proper feed of that page automatically.

4.       Be able to handle multimedia content.

5.       Be able to handle multiple standards (i.e. RSS flavors, ATOM, etc)

6.       be transparent to extensions such as SSE

The news module should concentrate on defining the aggregation and display. In its settings it will maintain a list of feeds. A feed can be from (1) an external source, (2) a module, (3) a page. The latter will aggregate content from the modules on that page.

The News module will communicate this to the syndication API and the latter will take care of the proper aggregation. The module can then concentrate on display. This could be modeled after the reports module that uses an extensible mechanism to render SQL output.