|
home
outline
![noseeum]()
|
|
 | What is the RCS Aggregator Cache? |
 | With this tool, the Radio Community Server can act as a RSS Cache for Radio Userland Aggregators. |
| The RCS is able to gather the most popular RSS feeds on behalf of an entire community of Radio Userland Users. The Users Aggregators request those feeds from the RCS, rather than directly from the source. |
| Content providers should receive significantly less requests of RSS feeds, resulting in less drain of bandwith and server resources. |
| At present, this problem isn't significant, but as the usage of Aggregation greatly increases, some steps will need to be taken to preserve an efficient architecture |
| This is a fully functional experiment for the Radio Userland platform. This functionality can be duplicated in other implementations. |
 | Install on RCS |
| The RSS Cache is now enabled. Have members of your community install the tool, according to the instructions below. |
| Install in Radio |
| Enable the caching client on the rcsAggregatorCache prefs page. If your RCS does not support RSS Caching, please contact them. |
| The Client Cache is now enabled. Aggregator requests will check with the cache before requesting directly from the source. |
| How does it work |
| This tool has two portions, one for the RCS and one for the client. |
| The RCS maintains a list of the 100 most popular subscriptions of its users. When RSS Caching is enabled, periodically (presently 4 times an hour) the RCS requests and stores these feeds. It only stores the raw XML, and does not process them. A GET interface is provided to clients to request the cached feeds. |
| For the Radio client, when the tool is enabled, a modified version of xml.aggregator.everyMinute is placed in the scheduler. This modified version will request and process the RSS Hotlist from the RCS, then run as a normal aggregator. Except, if a user's subscription is included in the Hotlist, the RCS Cache is queried for the feed. If that fails, the request is made directly from the provider. |
| Future Directions |
| There's lots of potential in the RCS. My next idea is to build a Hotlist of read articles, a sort of blogdex for actual reading habits. |
| Development Notes |
| Todos |
| next version |
| modified table - track whether original routines have changed, and notify author when that happens |
| Jake says this will work |
| local (adrobject = @addressOfTheThingToCheck); |
| local (adrmyversion = @addressOfMyBackupCopy); |
| if string (adrobject^) != string (adrmyversion^) { |
| //do your thing here |
| } |
| uninstall rcsAggregatorSuite.background.everyMinute if rcs is not |
| determine if installation is on rcs or local (or both) - this should be done for efficiency in order to uninstall background.everyMinute |
| rcsAggregatorCacheData.prefs.path should be set by install or by communication with rcs |
| allow user to select frequency of cache update. for now it runs at 0,15,30,and45 |
| selectively run updateCachelist, on startup and after rssHotlist has changed, instead of every 15 minutes in everyMinute |
| make sure xml request script runs immediately after radioCommunityServerSuite.rssHotlist.threadScript, if it goes through |
| for now, don't schedule another call, since there could be a conflict between rebuilding the rssHotlist if it runs more often; later we should update at least every 15 minutes |
| from client, should check rcs if it supports caching before trying |
| turn on rssHotlist if caching is turned on (and warn user) |
| Notes |
| rcsAggregatorCacheSuite.modified table contains routines from Radio.root that were copied and changed for use in the tool. |
| all modified lines will be suffixed with //MODIFIED |
| Completed |
| !!in rcs, cache table created manually!! |
| !!prefs in current .root were set manually!! |
| radio.hotlist.reload() - check to see if it's run periodically, if not call once per day or on startup or perhaps before every readAllServices |
| hotlist info is in hotlistData.top100.[001-100]. translate this table into a list of xmlUrls first, for xml.rss.readService to check. |
| initialization routine should |
| add 'enabled' pref for server/client |
| install scheduled routines - no it shouldn't - this should be done in enable |
| in rcs.cacheRss, thread call to request and store |
| prefs turn off/on caching; this will involve (un)installing scheduled routines (like everyMinute) as a precaution, readService scripts will double check this pref |
| on startup, run rcs readXml |
| in client.install, check that this is not overwritten, or undone, when aggregator is installed or inactivated |
| rcs readXml routine should try to limit number of threads, like readAllServices |
| check that the rcs has the rssHotlist set up |
| clean up the prefs function! |
|
|
© copyright 2006
by Mikel Maron.
|
opml 1.0