CacheableCustomizability

MeatballWiki | RecentChanges | Random Page | Indices | Categories

People like to customize the look of Wikis they use frequently, e.g. to change the position of links, or their default RecentChanges preferences.

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.

Therefore, push the cost onto the client by using WikiPedia:DHTML to enable customizability. Non-javascript-enabled browsers will see the default view of 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.

It also necessarily causes some duplication between client and server code, as the languages supported by both are in the large disjoint: Javascript (used in AJAX) is browser-only, while CGI (such as Perl or PHP) is inherently unsafe and so server-only. Code duplication is a fertile source of bugs and discrepancies.

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

: This is brilliant! One of the design features of InfiniteMonkey is that RecentChanges should just be a data feed of the list of changes. The list of changes can be sent anywhere. To another module inside the script, to another server, and in this case, to the client! This is exactly how a NetworkService? should work. -- SunirShah

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.

The Javascript now "knows" a little about how a Wiki RSS feed should act, and only needs to grab the smallest feed each auto-refresh even with years of updates on the page. The large feeds need only be downloaded once. This opens the door to AJAX scripts that cache a local copy of the feed for all eternity, synchronizing it with the server when the page is reopened.

I'm also interested in the possibility of more dynamic presentations of the RC information than replicating bog-standard HTML. Perhaps a simple digest-truncation option, with the whole digest popping up when the user hovers over it? Or a presentation that highlights who made the changes, for easier PeerReview? Or how about a timeline of changes that gradually move down the page as the updates get older? Someday soon, I may even have the Javascript/CSS skills needed for that latter. -- ChrisPurcell

CategoryWikiTechnology CategoryUncommonWikiTechnology

CacheableCustomizability

Discussion