parameter set -> get_cache_key
Implement this as part of the RequestHandler.
Application asks for a key based not he request method and the currently parameters.
Handler must return a key, or None. If None returned Caching process is skipped.
Application must pass a reference to a Cache Provider.
Cache Provider abstracts get / set.
Tried implementing this as a decorator, problems surround passing instance reference.
decorators seem to function on a class level.
Need to rethink the key generation and action.
Refer to implementation using decoators for rules and CacheKeyProviders.
Introduces CacheKeyProvider, to be used in conjunction CacheProviders.
cache package provides decorators
Use these to decorate handlers, all functionality is completely optional.
store happens at the end of the handler. Interacts with response to store the cache.
Handlers are auto sequenced.
Implemented in r236 doesn't do @cache.store properly
Support caching via using proper headers, http://www.mobify.com/blog/beginners-guide-to-http-cache-headers/
Consider the effect of things like NDB cache
After extended discussions with @BradMclain caching is very specific to the application and the backend it employs. This might be outside the scope of a project like prestans and might be the real of caching for backends like NDB or using dogpile for relational databases.
Even if the the writable response could be cached, complex authorisation rules would require accessing the backend per request. This would negate a swift response from the handler.
At present this has been deferred to be in the realm of the server or database environment.