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

Showing 1-13 of 13 messages
Intent to Implement and Ship: Quota Management API (unprefixed) Hiroki Nakagawa 1/16/14 4:19 AM

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.

Re: Intent to Implement and Ship: Quota Management API (unprefixed) afba...@gmail.com 1/16/14 10:00 AM
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
Re: [blink-dev] Re: Intent to Implement and Ship: Quota Management API (unprefixed) Hiroki Nakagawa 1/16/14 4:38 PM
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

Re: [blink-dev] Re: Intent to Implement and Ship: Quota Management API (unprefixed) Kinuko Yasuda 1/16/14 6:22 PM
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!


[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.



Re: [blink-dev] Re: Intent to Implement and Ship: Quota Management API (unprefixed) PhistucK 1/17/14 9:26 AM
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.

Re: [blink-dev] Re: Intent to Implement and Ship: Quota Management API (unprefixed) Kinuko Yasuda 1/19/14 5:50 PM
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.


Re: [blink-dev] Re: Intent to Implement and Ship: Quota Management API (unprefixed) Kinuko Yasuda 1/19/14 6:30 PM
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?)

Re: [blink-dev] Re: Intent to Implement and Ship: Quota Management API (unprefixed) Mike 1/19/14 8:32 PM
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
Re: [blink-dev] Re: Intent to Implement and Ship: Quota Management API (unprefixed) Darin Fisher 1/19/14 9:05 PM
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
Re: [blink-dev] Re: Intent to Implement and Ship: Quota Management API (unprefixed) Kinuko Yasuda 1/19/14 10:35 PM
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..

Re: [blink-dev] Re: Intent to Implement and Ship: Quota Management API (unprefixed) Darin Fisher 1/19/14 10:40 PM
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

Re: [blink-dev] Re: Intent to Implement and Ship: Quota Management API (unprefixed) Kinuko Yasuda 1/19/14 10:46 PM
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,

Re: [blink-dev] Re: Intent to Implement and Ship: Quota Management API (unprefixed) Hiroki Nakagawa 1/24/14 1:09 AM
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>