|Intent to Implement and Ship: Quota Management API (unprefixed)||Hiroki Nakagawa||1/16/14 4:19 AM|
kin...@chromium.org (spec editor)
Implement a newer and unprefixed version of Quota Management API according to the latest spec  and deprecate the current prefixed version .
The new API is promise-based and it would work better with newer specs like ServiceWorker . It has been getting no objections / positive feedback from Firefox.
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
Will this feature be supported on all five Blink platforms (Windows, Mac, Linux, Chrome OS and Android)?
OWP launch tracking bug?
Link to entry on the feature dashboard
Requesting approval to ship?
|Re: Intent to Implement and Ship: Quota Management API (unprefixed)||afba...@gmail.com||1/16/14 10:00 AM|
|Re: [blink-dev] Re: Intent to Implement and Ship: Quota Management API (unprefixed)||Hiroki Nakagawa||1/16/14 4:38 PM|
Right. That's what we would like to implement.
kinuko@: Can you update the spec ?
|Re: [blink-dev] Re: Intent to Implement and Ship: Quota Management API (unprefixed)||Kinuko Yasuda||1/16/14 6:22 PM|
 is the archived one which has its published date, the latest one is WD-quota-api-20131105 which is the same one as  you mentioned.
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 ( == 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!
|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)?
|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:
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  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 West||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. :)
|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.
|Re: [blink-dev] Re: Intent to Implement and Ship: Quota Management API (unprefixed)||Kinuko Yasuda||1/19/14 10:35 PM|
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).
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:
Note, the gap between step 1 and 2 can be small if you are confident that the API design is final.
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.
|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:
Makes sense. We do keep it behind a flag while building more consensus to the final version.
|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.
2014/1/20 Kinuko Yasuda <kin...@chromium.org>