Traditionally, this is done on the server, based on the user's cookie. This means the content sent out depends on the Cookie header, which prevents servers, proxies and browsers from caching pages. This means increased bandwidth and CPU-time costs for the site.
People like massively-customizable RecentChanges, with an infinity of combinations of parameters.
This means the content sent out depends on a huge variety of parameters passed in, and often also the Cookie header, which again prevents page caching.
Therefore, push the cost onto the client by using WikiPedia:AJAX to support flexibility. AJAX allows RecentChanges entries to be pulled off an RSS (or preferably WikiPedia:JSON) feed, filtered and formatted to the user's tastes, including automatic timezone handling; as a further bonus, it allows AsynchronousAutorefreshing of RecentChanges.
Load and server strain can be significantly reduced by supplying a limited number of cached and cacheable feeds covering pre-determined timespans (for example 5 days, a fortnight, a moon, a year or eternity). Existing AJAX browsers have hang-ups when it comes to supporting the Not-Modified-Since HTTP header, but this should get better in future, further improving the situation.
However, this pattern flies in the face of the current (mid-2005) cutting-edge of AJAX design: complex tasks are typically performed on the server. "Ruby on Rails", for example, makes this a guiding principle, using the client merely to download and position HTML.
Just an idea I've been working to implement. Good for the CV ;) For a basic implementation of the idea, take a look at my [completely cacheable MeatballWiki look-alike]. -- ChrisPurcell
I've been designing the script as a ground-up replacement for UseMod, with similar goals to IM. Strict adherence to CacheableCustomizability has been surprisingly helpful, as it allows the page caching mechanism to be transparent to all but the database access module. Since the HTML emitted must depend only on database lookups, the database module can determine exactly when a cache entry is invalidated, and regenerate it when next required. The same benefit will probably transfer to InfiniteMonkey.