胺 ` X 公坙公坙 公犂公犂 公坙公坙 n j . 公{f公犂
&
,cache Xhotlist stats n Z h z Arial
梗9公x p s 狶AND win 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.
Please send any comments, suggestions, bug reports to mikel_maron@yahoo.com. Have fun!
Install on RCS
Requirements: You must have the Radio Community Server installed, and RSS Hotlist enabled.
Download rcsAggregatorCache.root to you Radio Tools directory, and restart Radio.
Enable the RCS cache on the rcsAggregatorCache prefs page.
The RSS Cache is now enabled. Have members of your community install the tool, according to the instructions below.
Install in Radio
Requirements: Radio Userland, and an RCS that supports RSS Caching
Download rcsAggregatorCache.root to you Radio Tools directory, and restart 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!
Z ` 梗俎公 " ; G
% 躬&