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

Re: [quota-api] API change suggestions

From: Kinuko Yasuda <kinuko@chromium.org>
Date: Tue, 11 Sep 2012 18:13:15 +0900
Message-ID: <CAMWgRNYoPtTGk+toZXweM327q=hnoW482L4Y35k_ZF0jhUzw-g@mail.gmail.com>
To: Tobie Langel <tobie@fb.com>
Cc: "public-webapps@w3.org" <public-webapps@w3.org>
Hi,

Thanks for giving the continuous feedback to Quota API.

On Mon, Sep 10, 2012 at 7:46 PM, Tobie Langel <tobie@fb.com> wrote:

> Hi,
>
> I'm very happy with the API changes we where able to make to the Quota
> API, but there's a method name we have left untouched and that I haven't
> figured out how to tackle until today: queryUsageAndQuota.
>
> The name is horrendous and is going to make developers cringe. It's also
> not very extensible should need arise to provide extra information in the
> future.
>

I admit that the name is horrendous (!) but I think it is also very
(probably a bit too much) straightforward so that any consumers could
easily guess what it does.


> Here's a suggestion to fix it:
>
> 1) create a new StorageQuotaInfo interface:
>
> WebIDL:
>
> interface StorageQuotaInfo {
>   readonly attribute unsigned long long quota;
>   readonly attribute unsigned long long usage;
> };
>
>
> 2) Rename StorageUsageCallback to StorageInfoCallback and pass it a
> StorageQuotaInfo instead of two ints:
>
> WebIDL:
> callback StorageInfoCallback = void (StorageQuotaInfo storageQuotaInfo);
>
> 3) Rename queryUsageAndQuota to getInfo:
>
> WebIDL:
>
> interface StorageQuota {
>   void getInfo (in StorageInfoCallback successCallback, in optional
> StorageErrorCallback errorCallback);
>   ...
> };
>
> The examples in the spec would be rewritten as shown here:
> https://gist.github.com/3690242
>
>
> Thoughts?
>

I think I like this idea, but I'm also concerned with the fact that
Chromium has been shipping Quota API some time now and there're some
consumers of the old API.  Since we've already made several changes in the
API there's no reason that we cannot make further changes, but I want to be
a bit conservative about this.

I would like to examine: if we have obvious pros/cons in the current and
proposed API (like feature detection in the past API changes), and also
would like to wait a bit more to see if anyone has feedbacks/comments.

Thanks!
Kinuko


> Again, happy to contribute those changes if there's interest.
>
> Best,
>
> --tobie
>
>
Received on Tuesday, 11 September 2012 09:14:06 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:54 GMT