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?
Link to entry on the feature dashboard
http://www.chromestatus.com/features/6218562888794112
Requesting approval to ship?
Yes.
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?
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@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].
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
Is Chrome currently (and for the near future) the only browser that implements this API (prefix or not, whichever draft)?
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.-DarinOn 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.
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.-DarinOn 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..
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.-DarinOn 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.