W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2009

RE: DataCache API - editor's draft available

From: Adrian Bateman <adrianba@microsoft.com>
Date: Thu, 16 Jul 2009 15:31:32 -0700
To: Jonas Sicking <jonas@sicking.cc>, "Nikunj R. Mehta" <nikunj.mehta@oracle.com>
CC: public-webapps WG <public-webapps@w3.org>, Charles McCathieNevile <chaals@opera.com>, Arthur Barstow <art.barstow@nokia.com>
Message-ID: <749F45FA745A3244A87A63316D4E26B187C0000C76@NA-EXMSG-C108.redmond.corp.microsoft.com>
On Thursday, July 16, 2009 2:43 PM, Jonas Sicking wrote:
> Hi Nikunj,
> So one of the things I've never fully understood with your proposal is
> what usage patterns people are going to want to use this new API with.
> / Jonas
> On Thu, Jul 16, 2009 at 1:10 PM, Nikunj R.
> Mehta<nikunj.mehta@oracle.com> wrote:
> > I have published the first draft of the DataCache API, which is based
> on
> > Oracle's BITSY proposal [1]. Here's a link to the draft:
> >
> > http://dev.w3.org/2006/webapi/DataCache/

Nikunj, thanks for putting together the document and publishing it.

I agree with Jonas and I'd like to understand the expected use cases better too. I think I get the point that making the network access seamless regardless of whether there is network connectivity or not simplifies the network request code but seems to me to require more complex interception code. This isn't a pattern that I can readily map to customer requests we've received nor is it a familiar pattern to me personally.

The other concern that I have is that this seems like an extension to the AppCache support in HTML 5. The new part is the ability to denote certain end-points that respond dynamically via script including supporting verbs other than GET. On the other hand, it appears to me that it proposes an entirely new programming model - did you consider an incremental approach that modifies window.applicationCache? Did you have particular reasons for rejecting that?


Received on Thursday, 16 July 2009 22:33:14 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:17 UTC