anchor.diff:  The +:compressable+ key identifies which content types are compressable; note the use of the +/*+ suffix to indicate
   that all text content types are compressable.
   
  -File system caching is normally only enabled in development mode.
  -
  -Twixt always caches the content of files in memory, after any transforming operations. 
  -In development mode, checks are enabled to refresh the cache when underlying files are modified; 
  -in production, no such checks occur as it is assumed that all such assets are stable
  -(until the entire application is re-deployed).
  -
  -=== Future Plans
  +== Caching
  +
  +It is desirable to have Twixt be able to serve-up files quickly, especially in production.
  +However, that is counter-balanced by the need to ensure the *correct* content is served.
  +
  +=== Development Mode
  +
  +Twixt will cache the results of compilations to the file system; the cache persists between executions.
  +This means that on restart, the application will normally start right up, since the compiled files
  +will be accessed from the file system cache.
  +
  +Whenever a source file changes, the corresponding compiled file is rebuilt (and then the file system cache is updated).
  +This is great for development, as you will frequently be changing your source files.
  +
  +Twixt doesn't bother to cache the GZip compressed versions of assets to the file system; it is relatively quick
  +to rebuild the compressed byte stream. There's an in-memory cache of the compressed assets, but each request includes
  +checks to see if the compiled output itself must be updated.
  +
  +You may need to manually clear out the file system cache after upgrading to a new version of Twixt, or any other
  +configuration change that can affect the compiled output.
  +
  +=== Production Mode
  +
  +In production mode, Twixt starts from a clean slate; it does not use a file system cache. However, all assets
  +are cached in memory; Twixt also caches the compressed versions of assets, to save the cost of repeatedly compressing
  +them on the fly.
  +
  +In production mode, there are no checks to see if the in-memory cache is valid; if a source file is changed, it is assumed
  +that the entire application will be re-deployed and re-started.
  +
  +== Future Plans
   
   The goal is to achieve at least parity with Apache Tapestry, plus some additional features specific to Clojure. This means:
   
  
positive.code: directing the client to the correct resource (with the correct checksum). 
  This is an extremely unlikely scenario that would involve a running client in a race with a redeployed application.
  
  === Direct asset URLs
  
  Sometimes it is not possible to determine the full asset URL ahead of time; a common example would be a client-side
  framework, such as http://angularjs.org[AngularJS] that wants to load HTML templates dynamically, at runtime.
  
negative.code: * Aggregated CSS stacks
  * RequireJS support and AMD modules
  * Break out the the Less, Jade, CoffeeScript, and exception reporting support into a-la-carte modules
  * "Warm up" the cache at startup (in production)
  
  == Stability
  
  *Alpha*: Most features are not yet implemented and the code is likely to change in many ways going forward ... but still very
  useful!
  
  == A note about feedback
  
  http://tapestryjava.blogspot.com/2013/05/once-more-feedback-please.html[Feedback] is very important to me; I often find
  Clojure just a bit frustrating, because if there is an error in your code, it can be a bit of a challenge to track the problem
  