The HTTP protocol allows servers to specify the last modification date of a requested resource using the Last-Modified header. Clients can then include a If-Modified-Since header in subsequent requests for the same resource. The server can return a 304 ("not modified") return code to such requests to inform the client that the cached version is up-to-date. (See http://www.w3.org/Protocols/HTTP/HTRQ_Headers.html#if-modified-since for more info.)
BRIDGE includes support for automatically updating a lastModifiedTime property on all EmbeddedObjectDescriptors. Ideally the BRIDGE server would be able to automatically handle the relevant http headers based on the descriptor's last modification time, but it does not appear that this will be practical:
- The server has no way of knowing which kinds of objects are self-contained but dynamic, e.g., web counters.
- The server has no way of knowing which objects may embed other objects either explicitly or implicitly.
As an alternative, static methods setLastModifiedHeader and checkModificationDate have been added to DispatchServlet. Servlets may use these if appropriate to manage timestamp headers.
Initially it seems clear that this functionality can be added to cork.models.file.FileServer to allow caching of images and other static file data. Other possibilities include:
- Old versions of any object should be cachable. There may be cases where old versions contain embedded newer versions of other objects, but caching doesn't make this worse.
- Chat sessions can currently not embed other content, so these should be safe. We need to verify that modification times are being updated properly on these objects. (Actually, updating modification times with each message seems like a bad idea because of messaging traffic, so we probably don't want to do this.)
- Whiteboard objects could be made cacheable as long as they do not include images or other embedded content. A brute-force check for this on each request would probably still be worthwhile, since image rendering is slow and memory-intensive.
- Data tables should be cachable, though given how these are normally used the payoff is likely to be minimal.
- Given that there will likely always be some types of potentially cacheable objects for which it is too expensive to (e.g.) check the modification times of all embedded content, it might make sense to add the ability to let the user specify that an object should always be cached assuming modification date would permit this. In this way, users could choose to optimize things like long, slow pages if they wanted to.
|