Web Framework Caching

An idea I wanted to get down before I forget it: if I’m going to extend any templating system, and especially cs/Template, I want it to cache it’s templates.

Here’s the specifics: essentially, the new templating system would function identically, unless it was handed a CacheWatcher (or whatever.) Now, some of the resources that the template uses to produce the output of the document get cached. Includes would be a perfect example; once they’re included into the template, they should stay there until they need to be reloaded.

Now when the template gets an output call, it checks it’s CacheWatcher to see which of it’s resources are dirty. (The default behavior is that everything is dirty.) The motivational case is that the CacheWatcher treats vars, evals, withs, etc as dirty, and includes as clean, unless they’re made manually dirty.

How are they made dirty? Why with a RingService, of course! The whole point is that I can use a semi-static nav menu as an include, and know that it won’t slow the app down unduly. If I change the menu, I run a little mini-app that announces the path as being dirty, and all the templates that are using it will reload it (once) when they need it next.

Some more advanced usage might include filtering out vars by their lifecycle, and keeping them around while, for instance, a session is still open. Why dip into the DB all the time? Granted, it gets things more shared, but I think share nothing is mostly a guideline.