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
