This is a Call for Consensus (CfC) to publish the First Public
Working Draft (FPWD) of the DataCache API spec:
http://dev.w3.org/2006/webapi/DataCache/
This CfC satisfies the group's requirement to "record the group's
decision to request advancement".
By publishing this FPWD, the group sends a signal to the community to
begin reviewing the document. The FPWD reflects where the group is on
this spec at the time of publication; it does not necessarily mean
there is consensus on the spec's contents.
As with all of our CfCs, positive response is preferred and
encouraged and silence will be assumed to be assent. The deadline for
comments is October 24.
-Regards, Art Barstow
Begin forwarded message:
From: "ext Nikunj R. Mehta" <nikunj.me...@oracle.com>
Date: October 16, 2009 1:59:36 PM EDT
To: Web Applications Working Group WG <public-webapps@w3.org>
Subject: DataCache - revised editor's draft available
Archived-At: <http://www.w3.org/mid/16284379-AA22-433A-8BAC-
b3f9f65ac...@oracle.com>
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:
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 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