Re: [quota-api] API change suggestions

(Reviving this old thread as I'd like to make this API stable and would
like to see more feedbacks...)

Let me briefly summarize the proposed API change and its pros/cons:

* The existing API [getUsageAndQuota(), returns two long long integers] is
horrible but (hopefully) comprehensible.  As a Chrome-only benefit it looks
similar to the existing one so migrating to the new one would be easy (the
author doesn't need to change the callback code).

* The new proposed API [getStorageInfo(), returns a StorageInfo object] has
a shorter and cleaner name.  Another potential benefit is it may make it
easier to add more fields in StorageInfo (though its necessity is not known
yet). One downside is it requires API change from the first published draft
(while it'd be probably ok as currently no browser implements the spec'ed
version yet).

Given that I had no objection yet I'm feeling positive to incorporate this
change, but I'm still worried about the API's stability.  I want to make
this API attractive/reasonable enough but I do NOT want to make frequent
changes.

Since this thread has been dormant for a while let me wait a few more days
looking for more feedbacks.

Thanks!


On Wed, Sep 12, 2012 at 12:07 AM, Tobie Langel <tobie@fb.com> wrote:

> On 9/11/12 4:06 PM, "Charles McCathie Nevile" <chaals@yandex-team.ru>
> wrote:
>
> >On Tue, 11 Sep 2012 06:29:07 -0400, Kinuko Yasuda <kinuko@chromium.org>
> >wrote:
> >
> >> On Tue, Sep 11, 2012 at 6:43 PM, Tobie Langel <tobie@fb.com> wrote:
> >>> On 9/11/12 11:13 AM, "Kinuko Yasuda" <kinuko@chromium.org> wrote:
> >>>
> >>>> 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.
> >
> >But if they are going to have to changed from a prefixed API anyway it
> >should not be a big issue for them to change for real. (Otherwise we're
> >back in the situation where prefixing isn't going to work and was a bad
> >idea).
>
> Agreed.


Right, if we agree that the new API is better we plan to migrate Chrome's
API to the new one.

 >On the other hand, I can live with horrible but readily comprehensible
> >names - and the older I get the happier I am to put up with them
>
> Likewise. However, this is not how developers generally feel about it, and
> I would much rather spend a little time bike-shedding things here (and
> hopefully providing better APIs) than a lot of time arguing and/or
> explaining things after the fact.


>(or use some library that suits me, while others find their own path to
> >happiness).
>
> This looks good in theory but has associated costs in practice:
>
> - extra resource downloads,
> - need for the developer to maintain these libraries,
> - potential perf problems (higher memory footprint, slower code path),
> - no common APIs across different projects.
>
> --tobie
>
>