I promised in the last post I’d say a few words about the rendering process of the new module. This post is about the changes that are being made to the Newsfeeds module regarding rendering. The main issue I wanted to tackle is the delay your DNN page can experience if a feed needs to be retrieved from another site.
Current situation (v 03.01)
The current module gets a feed from somewhere and transforms this using an XSL stylesheet. When a page holding a Newsfeed module is rendered, the module will fetch the Rss before being able to return the transformed feed. There is a timeout of 10 seconds on this. Your page will not be rendered to the client while the server retrieves the feed (and transforms it, but that can be assumed to be instantaneous). So the page rendering might be delayed up to 10 seconds when you have a feed on the page. You might also have multiple feeds on a single page further increasing load times. In all this has the noticeable effect of making your page slow to load. Of course the output can be cached (and by default it will) but this still means that a first page hit after the cache timeout takes an inordinate amount of time to load. Not something you want. More frustratingly: if one of the source feeds goes offline your page keeps loading slow while trying to retrieve the dead feed. When it does render it shows a big red error. Again, not something you want.
For a start I wanted to benefit from Ajax. With Ajax you can render a page and draw in content after the page has fully loaded in the client. DNN has good wrappers around the MS Ajax classes to allow a graceful retreat to older technology if Ajax cannot be used. As a downside to this use of Ajax the module caching is no longer possible. If the whole module gets cached it will render empty because the Ajax allowed loading after the module has rendered. So the use of Ajax must be switched off if the module cache time is not 0.
A second addition is to implement more refined caching within the module. Now the rendered output is cached. But when you’re implementing aggregation, caching might need to be set for individual feeds. This is up to the admin to decide. The new module will cache feeds individually in SQL. This will also solve an issue if a feed is unavailable for a while. If caching the aggregated feed only, all individual feeds would need to be retrieved every time the aggregated feed would timeout. A single feed could ‘hold up’ the aggregated feed being ‘complete and fresh’ and would therefore lead to continued refreshes of all feeds. In the individual feed caching the faulty feed can be retrieved independent of the others. When the faulty feed finally arrives, it can be merged with the cached individual feeds.
The aggregated feed is cached on disk as a feed (i.e. not as rendered output). This will allow it to be used for various purposes later (i.e. for allowing others to retrieve the aggregated feed).
The result is that you can opt to use Ajax (if present) by setting the module cache time to 0. If one of the feeds needs retrieving the module will render empty to the client and will call back to the server after the page has loaded.
If either the module cache time is not 0 or Ajax is not present or no feed needs retrieving (i.e. the cached aggregated feed is ‘fresh’) then the module is rendered immediately.