DataCache - revised editor's draft available

Hello all,

Based on the feedback from WebApps WG [1], I went back and rewrote the  
draft of the DataCache API to make it possible to benefit from HTML5's  
AppCache implementations. Here's the latest draft of this API:

http://dev.w3.org/2006/webapi/DataCache/

I note that there were several requests to describe how DataCache  
could be implemented along side HTML5's AppCache. From Adrian's  
message on this issue [2]:

What I'm asking for is a more unified proposal that says "If you have  
already implemented AppCache, here's what you add to make the same  
cache provide the additional functionality needed to enable these  
additional use cases." This will inevitably be a compromise from what  
a pure implementation looks like (your current DataCache spec, say)  
but lots of the web is necessarily a compromise because it builds on  
prior art that might not have been ideal but has been specified, built  
and deployed (and not always in that order).

Over and above an AppCache, here are the things a DataCache needs:

A data cache does not have fallback or online whitelist namespaces or  
foreign entries.
A data cache provides a monotonically increasing numeric version  
identifier.
A data cache may have an authorization cookie.
Every resource managed in a data cache may be configured to process  
certain (HTTP) protocol methods locally
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].
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.
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.
Update transactions can be performed in workers but not in the  
background independently of applications.
It is possible to have only one online transaction but multiple off- 
line transactions are allowed.
It is possible to find out the resources added to or removed from  
cache starting at a certain version.
A data cache offers applications the ability to get the contents  
corresponding to a URI.
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.
A new header is defined to by-pass data cache in request processing
A slightly different networking model is required to take into account  
interception.

I welcome your feedback on this draft and look forward to discussing  
this draft either on this DL or otherwise.

Several members [3] expressed interest in this spec and we have agreed  
that this spec really is covered in our WG's charter. Therefore, I  
would like request FPWD of this spec in advance of TPAC, if possible.

Regards,
Nikunj
http://o-micron.blogspot.com

[1] http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0246.html
[3] http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0306.html
[4] http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0329.html 
, http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0315.html 
, http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0316.html 
,  http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0096.html