CfC: to publish First Public Working Draft of DataCache API spec; deadline Oct 24

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.mehta@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- 
> B3F9F65AC43E@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
>

Received on Saturday, 17 October 2009 14:47:42 UTC