Intent to Implement and Ship: Quota Management API (unprefixed)

159 views
Skip to first unread message

Hiroki Nakagawa

unread,
Jan 16, 2014, 7:19:53 AM1/16/14
to blin...@chromium.org

Contact emails

nhi...@chromium.org (eng)

kin...@chromium.org (spec editor)


Spec

http://www.w3.org/TR/quota-api/


Summary

Implement a newer and unprefixed version of Quota Management API according to the latest spec [1] and deprecate the current prefixed version [2].


[1] http://www.w3.org/TR/quota-api/

[2] http://www.w3.org/TR/2012/WD-quota-api-20120703/


Motivation

The new API is promise-based and it would work better with newer specs like ServiceWorker [3]. It has been getting no objections / positive feedback from Firefox.


[3] https://github.com/slightlyoff/ServiceWorker/


Compatibility Risk

This API can be separated into two parts: promise-based query/request methods and events. For the former one compatibility risk would be low, while the latter one’s compatibility risk could be low to med, as it is relatively new and it may need more time to get mature. The old version of API will be kept available until we make sure the usage becomes low.


Ongoing technical constraints

None.


Will this feature be supported on all five Blink platforms (Windows, Mac, Linux, Chrome OS and Android)?

Yes.


OWP launch tracking bug?

http://crbug.com/332325


Link to entry on the feature dashboard

http://www.chromestatus.com/features/6218562888794112


Requesting approval to ship?

Yes.

afba...@gmail.com

unread,
Jan 16, 2014, 1:00:19 PM1/16/14
to blin...@chromium.org
Hi Hiroki,

Re [2] below, please note on 5-Nov-2013, a new draft was published <http://www.w3.org/TR/2013/WD-quota-api-20131105/>. Is this later version the one you intend to implement?

@AFBarstow

Hiroki Nakagawa

unread,
Jan 16, 2014, 7:38:22 PM1/16/14
to afba...@gmail.com, blin...@chromium.org, Kinuko Yasuda
Hi afbarstow@,

2014/1/17 <afba...@gmail.com>

Hi Hiroki,

Re [2] below, please note on 5-Nov-2013, a new draft was published <http://www.w3.org/TR/2013/WD-quota-api-20131105/>. 
Is this later version the one you intend to implement?

Right. That's what we would like to implement.

kinuko@: Can you update the spec [2]?

Thanks,
nhiroki

Kinuko Yasuda

unread,
Jan 16, 2014, 9:22:26 PM1/16/14
to Hiroki Nakagawa, afba...@gmail.com, blink-dev
On Fri, Jan 17, 2014 at 9:38 AM, Hiroki Nakagawa <nhi...@chromium.org> wrote:
Hi afbarstow@,

2014/1/17 <afba...@gmail.com>

Hi Hiroki,

Re [2] below, please note on 5-Nov-2013, a new draft was published <http://www.w3.org/TR/2013/WD-quota-api-20131105/>. 
Is this later version the one you intend to implement?

Right. That's what we would like to implement.
 
kinuko@: Can you update the spec [2]?

[2] is the archived one which has its published date, the latest one is WD-quota-api-20131105 which is the same one as [1] you mentioned.

Thanks,
nhiroki
 

@AFBarstow

On Thursday, January 16, 2014 7:19:53 AM UTC-5, Hiroki Nakagawa wrote:

Contact emails

nhi...@chromium.org (eng)

kin...@chromium.org (spec editor)


Spec

http://www.w3.org/TR/quota-api/


Summary

Implement a newer and unprefixed version of Quota Management API according to the latest spec [1] and deprecate the current prefixed version [2].


Let me clarify that this mail is to announce our intent to:
1) implement and ship the new promise-based Quota API as is in the latest draft ([1] == http://www.w3.org/TR/2013/WD-quota-api-20131105/), and
2) to deprecate Chrome's current prefixed API implementation which is based on the old draft. (http://www.w3.org/TR/2012/WD-quota-api-20120703/)

Chrome's been shipping the prefixed Quota API implementation for a while, and we feel that it's getting somewhat mature, i.e. the necessity of the API and its basic functionality (request and query quota for temporary/persistent (and possibly more) storage types) is getting some consensus.  There was one disagreement in the old draft, though, as it was using 'callback' for async methods while event-based API was proposed by Mozilla.  The latest spec addresses this issue by introducing Promises, which also got very positive feedback from Mozilla, so here we announce that we want to implement and ship unprefixed Quota API based on the promise-based latest spec, hopefully to reduce API fragmentation.  Any feedback is welcome!

PhistucK

unread,
Jan 17, 2014, 12:26:35 PM1/17/14
to Kinuko Yasuda, Hiroki Nakagawa, afba...@gmail.com, blink-dev
Is Chrome currently (and for the near future) the only browser that implements this API (prefix or not, whichever draft)?


PhistucK


To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Kinuko Yasuda

unread,
Jan 19, 2014, 8:50:03 PM1/19/14
to PhistucK, Hiroki Nakagawa, Arthur Barstow, blink-dev
On Sat, Jan 18, 2014 at 2:26 AM, PhistucK <phis...@gmail.com> wrote:
Is Chrome currently (and for the near future) the only browser that implements this API (prefix or not, whichever draft)?

Yes, unfortunately.  Mozilla is shoring interest to implement this, though no one's started working on it yet afaik.

Kinuko Yasuda

unread,
Jan 19, 2014, 9:30:06 PM1/19/14
to PhistucK, Hiroki Nakagawa, Arthur Barstow, blink-dev
We could just implement a newer version in a *prefixed* way and deprecate the old implementation (so dropping the 'ship' part from this intent) and wait until other browsers implement it instead, as we've been doing so far.  Probably it's more appropriate action at this stage?

(I was concerned about our "no-more-vendor-prefix" policy, but re-reading [1] it says it basically applies to a new feature (and in the case we should use about:flags), while prefixed Quota API has been around for a while-- so keep providing (and updating) a prefixed version would be fine for the time being, am I right?)

Mike West

unread,
Jan 19, 2014, 11:32:17 PM1/19/14
to Kinuko Yasuda, PhistucK, Hiroki Nakagawa, Arthur Barstow, blink-dev
If we don't believe the API is stable enough to implement prefix-free, I'd very much prefer to see us implement the unprefixed version behind a flag. If it is stable enough, we should just ship the unprefixed version.

If Mozilla is on board with the spec in its current form, would it be reasonable to push the working draft towards CR? That would make the "ready to ship" decision more straightforward.

Either way, I don't think we should make significant changes to prefixed APIs, unless those changes involve deprecation and removal. :)

-mike

-Mike

Darin Fisher

unread,
Jan 20, 2014, 12:05:09 AM1/20/14
to Mike West, Kinuko Yasuda, PhistucK, Hiroki Nakagawa, Arthur Barstow, blink-dev
We don't implement or ship new prefixed APIs.

I think there are 3 steps here:

1) Implement the new API, unprefixed behind a flag.
2) Ship the new API, unprefixed. No longer behind a flag.
3) Remove the old, prefixed API.

I think it is reasonable to space out these steps.

-Darin

Kinuko Yasuda

unread,
Jan 20, 2014, 1:35:44 AM1/20/14
to Darin Fisher, Mike West, PhistucK, Hiroki Nakagawa, Arthur Barstow, blink-dev
On Mon, Jan 20, 2014 at 2:05 PM, Darin Fisher <da...@chromium.org> wrote:
We don't implement or ship new prefixed APIs.

I think there are 3 steps here:

1) Implement the new API, unprefixed behind a flag.

The fact that we already have a prefixed implementation (which is available without a flag) made me worry that existing apps will unlikely migrate to the new version until we do stage 2), which slightly feels like a chicken-egg problem.

However it'd be also important to get feedback from developers first, and we could try encourage/educate developers to use the new API with the flag while we're in stage 1), so I hope we could work out.  (I'll ask for help from our devrel folks to see how we could smoothly communicate with developers)

Ok, so our first revised intent would be: Intent to implement: new promise-based Quota API (unprefixed)

This'll be behind a flag, as in our regular steps.  We'll keep the prefixed old version until stage 3).

2) Ship the new API, unprefixed. No longer behind a flag.
3) Remove the old, prefixed API.

I think it is reasonable to space out these steps.

-Darin

On Sun, Jan 19, 2014 at 8:32 PM, Mike West <mk...@chromium.org> wrote:
If we don't believe the API is stable enough to implement prefix-free, I'd very much prefer to see us implement the unprefixed version behind a flag. If it is stable enough, we should just ship the unprefixed version.

If Mozilla is on board with the spec in its current form, would it be reasonable to push the working draft towards CR? That would make the "ready to ship" decision more straightforward.

They say they need to have actual implementor look into it in details, and we'll probably have some minor changes, but yes I'll try to see if we can move it forward..

Darin Fisher

unread,
Jan 20, 2014, 1:40:23 AM1/20/14
to Kinuko Yasuda, Mike West, PhistucK, Hiroki Nakagawa, Arthur Barstow, blink-dev
On Sun, Jan 19, 2014 at 10:35 PM, Kinuko Yasuda <kin...@chromium.org> wrote:
On Mon, Jan 20, 2014 at 2:05 PM, Darin Fisher <da...@chromium.org> wrote:
We don't implement or ship new prefixed APIs.

I think there are 3 steps here:

1) Implement the new API, unprefixed behind a flag.

The fact that we already have a prefixed implementation (which is available without a flag) made me worry that existing apps will unlikely migrate to the new version until we do stage 2), which slightly feels like a chicken-egg problem.

However it'd be also important to get feedback from developers first, and we could try encourage/educate developers to use the new API with the flag while we're in stage 1), so I hope we could work out.  (I'll ask for help from our devrel folks to see how we could smoothly communicate with developers)

Ok, so our first revised intent would be: Intent to implement: new promise-based Quota API (unprefixed)

This'll be behind a flag, as in our regular steps.  We'll keep the prefixed old version until stage 3).


Note, the gap between step 1 and 2 can be small if you are confident that the API design is final.

 
2) Ship the new API, unprefixed. No longer behind a flag.
3) Remove the old, prefixed API.

I think it is reasonable to space out these steps.

-Darin

On Sun, Jan 19, 2014 at 8:32 PM, Mike West <mk...@chromium.org> wrote:
If we don't believe the API is stable enough to implement prefix-free, I'd very much prefer to see us implement the unprefixed version behind a flag. If it is stable enough, we should just ship the unprefixed version.

If Mozilla is on board with the spec in its current form, would it be reasonable to push the working draft towards CR? That would make the "ready to ship" decision more straightforward.

They say they need to have actual implementor look into it in details, and we'll probably have some minor changes, but yes I'll try to see if we can move it forward..

Seems like a fairly good reason to separate Intent to Implement from Intent to Ship. Not that you need to wait for CR, but getting to a point where you feel confident that we probably won't see any minor changes to the API would help.

-Darin

Kinuko Yasuda

unread,
Jan 20, 2014, 1:46:10 AM1/20/14
to Darin Fisher, Mike West, PhistucK, Hiroki Nakagawa, Arthur Barstow, blink-dev
On Mon, Jan 20, 2014 at 3:40 PM, Darin Fisher <da...@chromium.org> wrote:
On Sun, Jan 19, 2014 at 10:35 PM, Kinuko Yasuda <kin...@chromium.org> wrote:
On Mon, Jan 20, 2014 at 2:05 PM, Darin Fisher <da...@chromium.org> wrote:
We don't implement or ship new prefixed APIs.

I think there are 3 steps here:

1) Implement the new API, unprefixed behind a flag.

The fact that we already have a prefixed implementation (which is available without a flag) made me worry that existing apps will unlikely migrate to the new version until we do stage 2), which slightly feels like a chicken-egg problem.

However it'd be also important to get feedback from developers first, and we could try encourage/educate developers to use the new API with the flag while we're in stage 1), so I hope we could work out.  (I'll ask for help from our devrel folks to see how we could smoothly communicate with developers)

Ok, so our first revised intent would be: Intent to implement: new promise-based Quota API (unprefixed)

This'll be behind a flag, as in our regular steps.  We'll keep the prefixed old version until stage 3).

Note, the gap between step 1 and 2 can be small if you are confident that the API design is final. 
 
2) Ship the new API, unprefixed. No longer behind a flag.
3) Remove the old, prefixed API.

I think it is reasonable to space out these steps.

-Darin

On Sun, Jan 19, 2014 at 8:32 PM, Mike West <mk...@chromium.org> wrote:
If we don't believe the API is stable enough to implement prefix-free, I'd very much prefer to see us implement the unprefixed version behind a flag. If it is stable enough, we should just ship the unprefixed version.

If Mozilla is on board with the spec in its current form, would it be reasonable to push the working draft towards CR? That would make the "ready to ship" decision more straightforward.

They say they need to have actual implementor look into it in details, and we'll probably have some minor changes, but yes I'll try to see if we can move it forward..

Seems like a fairly good reason to separate Intent to Implement from Intent to Ship. Not that you need to wait for CR, but getting to a point where you feel confident that we probably won't see any minor changes to the API would help.

Makes sense.  We do keep it behind a flag while building more consensus to the final version.

Thanks,

Hiroki Nakagawa

unread,
Jan 24, 2014, 4:09:21 AM1/24/14
to Kinuko Yasuda, Darin Fisher, Mike West, PhistucK, Arthur Barstow, blink-dev
Thank you for your comments, and sorry for the delay in my response.

As kinuko@ mentioned, please let me change our intent like "Intent to implement: new promise-based Quota Management API (unprefixed)". After making more consensus on that, we would like to ship it.

Please let me know if you have any questions or concerns.

Thanks,


2014/1/20 Kinuko Yasuda <kin...@chromium.org>
Reply all
Reply to author
Forward
0 new messages