- From: Kinuko Yasuda <kinuko@chromium.org>
- Date: Wed, 21 Dec 2011 18:01:29 +0900
- To: Charles McCathieNevile <chaals@opera.com>
- Cc: Arthur Barstow <art.barstow@nokia.com>, public-webapps <public-webapps@w3.org>, Ian Fette <ifette@google.com>
- Message-ID: <CAMWgRNbwjujfLS=n9syAYE=Lo7vqFKqu+j_nOvjFyRs6P9jusw@mail.gmail.com>
Hi, (Sorry for my slow response, I'm in a half-vacation status) On Sun, Dec 18, 2011 at 12:19 AM, Charles McCathieNevile <chaals@opera.com>wrote: > On Fri, 16 Dec 2011 10:10:45 +0100, Kinuko Yasuda <kinuko@chromium.org> > wrote: > > On Thu, Dec 15, 2011 at 9:19 PM, Arthur Barstow <art.barstow@nokia.com >> >wrote: >> >> Hi Kinuko, All, >>> >>> Besides the Chromium team, I think it would be helpful if other browser >>> vendors would state their level of interest for this API (e.g. would >>> review drafts, prototype, deploy, etc.). >>> >> > We will at least review - in principle this is really useful for > application developers. > (Comment 1 - why does this need to use callbacks?) Thanks for the comment! This question could be interpreted two different ways: 1. Why this needs to be async? We wanted to make them async operations since querying the usage or updating the quota in the UA may require some blocking operations, like examining the actual disk usage or querying the backend database. 2. Why we use callbacks instead of events? I know there's a long history of callbacks vs events discussion, but the reason in our case was simple: The Quota API proposal was fleshed out along with the FileSystem API [1], which is the first storage API draft that has the concept of 'temporary' vs 'persistent' storage we wanted to introduce in the Quota API, and this motivated us to use the API notation similar to FileSystem API (i.e. callbacks). One of the obvious benefit of "events" is, in my understanding, in that way we could naturally implement "progress" events or "abort" method, both could be crucial in streaming processing, but in the quota case either one doen't seem to be really necessary. Events could also naturally allow multiple listeners but again this doesn't seem crucial in the quota API. I'm open to change this though if we have legitimate reasons strong enough to change existing chrome code. (I'll fork a new thread if this discussion could become longer) [1] dev.w3.org/2009/dap/file-system/file-dir-sys.html Kinuko - do you have a commitment for the Editor role and testing related >>> tasks e.g. creating a test suite? >>> >> >> >> Yes I'm willing to play the Editor role. >> As for the testing related tasks I'm not fully sure the necessary steps >> and deliverables, >> > > Making sure there are tests for the specification so it can be completed > and anyone can use them to demonstrate interoperability between any two > implementations... > Thanks, several people also kindly told me what'd be the expected tasks. > Given the basic nature of the spec I guess it doesn't need to be an > enormous test suite - the most complex question is probably checking that > it really works as advertised with different types of storage. (Although I > am not sure what the quota would actually *mean* for a database). For database we have no way to express 'temporary' or 'persistent' in the current spec, so the UA needs to store its data either in temporary or persistent. In the current chrome implementation we treat all the data of Web SQL, IndexedDB and AppCache as 'temporary' storage data, i.e. they can store some data without showing user prompting but the data could get deleted when the remaining space becomes low. (I'm aware that this part needs to be fleshed out more in terms of interoperability.) but yes I'm willing to do the tasks that need to be done to >> move this forward. >> > > In light of the above explanation? > Yes. cheers > > Chaals > > -AB >>> >>> >>> >>> On 12/13/11 7:23 AM, ext Arthur Barstow wrote: >>> >>> Subject corrected ... >>>> >>>> On 12/13/11 7:22 AM, Arthur Barstow wrote: >>>> >>>> As IanF mentioned before, Google would like to add a Quota API to >>>>> WebApps' charter and Kinuko has now provided a link to a document that >>>>> provides some details about this API: >>>>> >>>>> http://wiki.whatwg.org/wiki/****Quota<http://wiki.whatwg.org/wiki/**Quota> >>>>> <http://wiki.whatwg.org/**wiki/Quota<http://wiki.whatwg.org/wiki/Quota> >>>>> > >>>>> >>>>> >>>>> As such, this is a Call for Consensus to add this API to WebApps' >>>>> charter (see [CharterChanges] for latest data on WebApps' charter >>>>> update). >>>>> >>>>> If you have any comments or concerns about this proposal, please send >>>>> them to public-webapps by December 20 at the latest. >>>>> >>>>> As with all of our CfCs, positive response is preferred and encouraged >>>>> and silence will be assumed to be agreement with the proposal. >>>>> >>>>> -AB >>>>> >>>>> [CharterChanges] http://www.w3.org/2008/**** >>>>> webapps/wiki/CharterChanges<http://www.w3.org/2008/**webapps/wiki/CharterChanges> >>>>> <ht**tp://www.w3.org/2008/webapps/**wiki/CharterChanges<http://www.w3.org/2008/webapps/wiki/CharterChanges> >>>>> > >>>>> >>>>> >>>>> >>>>> -------- Original Message -------- >>>>> Subject: Re: Quota API and WebApps [Was: Re: Consolidating charter >>>>> changes] >>>>> Date: Tue, 13 Dec 2011 17:22:38 +0900 >>>>> From: ext Kinuko Yasuda <kinuko@chromium.org> >>>>> To: Arthur Barstow <art.barstow@nokia.com> >>>>> CC: public-webapps <public-webapps@w3.org>, Ian Fette < >>>>> ifette@google.com> >>>>> >>>>> >>>>> >>>>> Hi Arthur, >>>>> >>>>> On Wed, Nov 23, 2011 at 10:20 PM, Arthur Barstow < >>>>> art.barstow@nokia.com<mailto: >>>>> art.barstow@nokia.com>**> wrote: >>>>> >>>>> Hi IanF, All, >>>>> >>>>> Following up on Quota API vis-à-visCharterChanges wiki [1] ... >>>>> >>>>> Does the group want to add Quota API to the group's charter? If yes, >>>>> where is a draft/strawman proposal? >>>>> >>>>> >>>>> We have an early draft for Quota API spec here: >>>>> http://wiki.whatwg.org/wiki/****Quota<http://wiki.whatwg.org/wiki/**Quota>< >>>>> http://wiki.whatwg.org/wiki/**Quota<http://wiki.whatwg.org/wiki/Quota> >>>>> > >>>>> >>>>> >>>>> I think we want to add it to the group's charter. >>>>> >>>>> -AB >>>>> >>>>> [1] http://www.w3.org/2008/****webapps/wiki/CharterChanges<http://www.w3.org/2008/**webapps/wiki/CharterChanges> >>>>> <ht**tp://www.w3.org/2008/webapps/**wiki/CharterChanges<http://www.w3.org/2008/webapps/wiki/CharterChanges> >>>>> > >>>>> >>>>> >>>>> On 11/8/11 12:37 PM, ext Arthur Barstow wrote: >>>>> >>>>> During the October 31 meeting, we discussed [1] various >>>>> additions, changes and deletions for WebApps' current charter >>>>> [2]. To consolidate the various proposals, I created the >>>>> following doc: >>>>> >>>>> <http://www.w3.org/2008/****webapps/wiki/CharterChanges<http://www.w3.org/2008/**webapps/wiki/CharterChanges> >>>>> <ht**tp://www.w3.org/2008/webapps/**wiki/CharterChanges<http://www.w3.org/2008/webapps/wiki/CharterChanges> >>>>> > >>>>> >>>>> > >>>>> >>>>> My expectation is that Doug will this information when he drafts >>>>> our updated charter. >>>>> >>>>> Comments on this doc and our future charter welcome. However, if >>>>> we are going to add any new deliverables, I think there should >>>>> be broad agreement on the spec, including prior commitment to >>>>> drive the spec through all of the phases of the process >>>>> including testing and implementations. >>>>> >>>>> Chaals, IanF - I included some actions/questions for you (mostly >>>>> recorded at the f2f meeting). >>>>> >>>>> -AB >>>>> >>>>> [1] http://www.w3.org/2011/10/31-****webapps-minutes.html<http://www.w3.org/2011/10/31-**webapps-minutes.html> >>>>> <http://**www.w3.org/2011/10/31-webapps-**minutes.html<http://www.w3.org/2011/10/31-webapps-minutes.html> >>>>> > >>>>> [2] http://www.w3.org/2010/****webapps/charter/<http://www.w3.org/2010/**webapps/charter/> >>>>> <http://www.**w3.org/2010/webapps/charter/<http://www.w3.org/2010/webapps/charter/> >>>>> > >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> > > -- > Charles 'chaals' McCathieNevile Opera Software, Standards Group > je parle français -- hablo español -- jeg kan litt norsk > http://my.opera.com/chaals Try Opera: http://www.opera.com >
Received on Wednesday, 21 December 2011 09:02:23 UTC