Archive of UserLand's first discussion group, started October 5, 1998.

Re: Interactive RSS channels

Author:James Carlyle
Posted:9/23/1999; 12:07:44 PM
Topic:Interactive RSS channels
Msg #:11402 (In response to 11358)
Prev/Next:11401 / 11403

The 'proof of concept' version that we have running doesn't really do anything intelligent. As I said, xmlTree is focusing on being a directory of xml content, but I had this idea for what an interactive RSS channel might look like, and a burning desire to implement it. We would like to see the portal developers make it more usable / intelligent, if they see any mileage in it.

When we cache the channel, we are actually caching the HTML-transformed content, not the raw XML. This is obviously for performance reasons - if an interactive RSS channel is to be displayed on the same page as some static ones, then the server has to output all the channels each time the user does something with the interactive channel. Of course if the channels were displayed in IFRAMES then this wouldn't be a problem.

The static channels are cached in an ordinary way and at the server (application) level - when the cache times out, the cache is refreshed. This means that static channel content which comes from the application cache looks the same for everyone.

The interactive channel content is cached at the session level, so each user will have a copy of different content. In this way, the channel is personalised for each user - so if user #1 searches for 'sport', his content will contain sports items, and user #2 will not see them.

How does the portal server recognise which channels are interactive? The interactive channels themselves are pure RSS. For this demo, the portal server assumes that they're interactive if they have the RSS text box and submit button. In this case, when the portal server renders the channel, the XSL changes the action of the RSS form to the portal server itself, and the true URL of the fulfillment server is stored in a hidden field. The portal server picks up the request, forwards it to the fulfillment server, receives the reply, and places it in the session cache for that user. Now when the users page is displayed, the static channels will come from the application (server-wide) cache and the interactive channel will come from the session (user-specific) cache.

Actually I know that the portal developers are doing (or should be doing) clever things with the cache themselves - for example, only showing headlines which have appeared in the channel since the last time the user looked. But in every instance where the channel contents presented to the user depend on the user, some form of session (user) cache will be required, somewhere.

James

There are responses to this message:

This page was archived on 6/13/2001; 4:52:47 PM.

© Copyright 1998-2001 UserLand Software, Inc.