![[Home]](http://meatballwiki.org/meatball.gif)
AggressiveCaching
MeatballWiki | RecentChanges | Random Page | Indices | CategoriesAggressive caching is a web-engine philosophy that really needs to be adhered to from step 1 to be thorough. The basic idea is to cache every output that's not one-shot, but with a strong record of dependencies to ensure caches are invalidated exactly when they need to be.
HTML emitted from a wiki tends to depend on properties of either one page, or the wiki as a whole:
- A page's existence, e.g. whether to flag a link as broken.
- A page's content, e.g. to render it as HTML, or present it as raw wiki
- A page's back-links
- The recent changes feed of the entire wiki (can be modeled as a property of the RecentChanges page, which then extends naturally to PageClusters)
By associating a unique identifier with each unique access point to the wiki (URLs, methods, parameters...), the engine can easily store and retrieve HTML and other data types from the database. If the identifier represents all external input to the engine, then cache invalidation can safely be done transparently by the database interface when data is altered. Further, storage of dependencies can also be done transparently when data is requested.
A relational database can manage AggressiveCaching, even in the face of future extensions to the wiki's database interface, with just two tables.
- The cache itself maps each identifier (PRIMARY KEY) to the type of data output (e.g. text/xhtml), the data itself, and the timestamp of entry creation. This latter allows automatic handling of HTTP's Last-Modified response header, and its If-Not-Modified conditional request header.
- The dependencies store three-part relationships: the identifier of the cache entry, the page the cache depends on, and what property of the page is involved (e.g. "content", "backlinks", "cluster feed"). Any request of a property of a page gets added to the dependencies; any modification to a property of a page causes all dependencies to get purged.
This design has proven itself in the experimental PeriPeri/2 wiki engine.
This seems like it would benefit from combination with SingleDispatch to provide a unique RESTful description of the current invocation. Is that what you mean by "associating a unique identifier with each unique access point to the wiki" ? -- SunirShah