DataCache API now rewritten and ready for FPWD

There was a wave of support for programmable HTTP caching when the first DataCache editor's draft was published. The main issue with the draft was the inability to derive the exact list of additional requirements on browsers compared with HTML5's AppCache. I went ahead and rewrote DataCache to make it easier to spot the differences. Here are the differences:

1. A data cache does not have fallback or online whitelist namespaces or foreign entries.
2. A data cache provides a monotonically increasing numeric version identifier.
3. A data cache may have an authorization cookie.
4. Every resource managed in a data cache may be configured to process certain (HTTP) protocol methods locally
5. Zero or more data caches are automatically associated with a cache host at its creation/load time. A secure data cache group is available to a cache host if its authorization cookie will be sent to an origin server for fetching that cache host [RFC2965].
6. The events checking and noupdate are not used. The events cached and updateready are merged in to a single event ready. Events downloading and progress are renamed as fetching and captured. There is no downloading update status for a data cache group.
7. No manifest is used. Instead an update transaction encapsulates a set of changes to the cache. An update transaction consists of any number of capture steps or release steps. An application can store a bag of bits independent of a network representation of that resource. This allows storing of off-line resources. The results are not visible until the transaction is committed.
8. Update transactions can be performed in workers but not in the background independently of applications.
9. It is possible to have only one online transaction but multiple off-line transactions are allowed.
10. It is possible to find out the resources added to or removed from cache starting at a certain version.
11. A data cache offers applications the ability to get the contents corresponding to a URI.
12. The navigator registers a scriptable HTTP interceptor that can off-line respond to arbitrary HTTP requests based on prior (data cache) configuration of the resources in those requests.
13. A new header is defined to by-pass data cache in request processing
14. A slightly different networking model is required to take into account interception.

I have a request to publish this new editor's draft as a FPWD and hopefully that will happen before TPAC with a view to discussing the draft during WebApps WG f2f meeting. Read this in conjunction with WebSimpleDB so you can create off-line Web apps that can serve HTTP resources locally, including even query on the off-line cache.