Intent to rename Service Worker's clients.getAll() to clients.matchAll() & adding support for its ClientQueryOptions argument

[Kenji Baheux]

Contact emails

Engineering: ksak...@chromium.org, kin...@chromium.org  

PM: kenji...@chromium.org

Spec

Editor's draft (W3C Public Working Draft)

Summary

We would like to rename clients.getAll to clients.matchAll (crbug/451334). We’ve been issuing deprecation warnings for clients.getAll and had matchAll shipped since M42.

In addition, we would like to add support for its optional ClientQueryOptions argument (crbug/460415, crbug/455241) in M43.

API level detail (relevant changes in bold)

Support for ClientQueryOptions will let developers:

• match all clients including yet to be controlled clients or just clients that are controlled

• match clients by type (e.g. window, worker, sharedworker, all)

Link to “Intent to Deprecate” thread

Note: we didn’t have an explicit intent to deprecate thread for deprecating getAll.

Motivation

For consistency, getAll has been renamed to matchAll in the spec (issue/610). We believe that we should remove getAll while adoption is still relatively low.

Usage information from UseCounter

Unfortunately, it seems that UseCounter can’t be used in a worker context. We do have an upper bound which seems reasonable though.

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS and Android, Android WebView)?

Yes.

Compatibility Risk

Pluses and minuses:

+ This is a relatively small change to a shipping API surface.

+ We’ve been issuing deprecation warnings about getAll in M42.

- No usage metrics because usage counter is not supported in a worker context

 + but the upper bound is reasonable.

+ Mozilla has already renamed getAll to matchAll (mozilla/1130685) in their on-going implementation of Service Worker.

Link to entry on the feature dashboard

http://www.chromestatus.com/feature/6561526227927040

Sidenotes

Update about debuggability

In M43, debugging Service Workers has become much simpler.

• Web developers will now be able to debug their controlling service worker and their website within the same devtools window.

• Head over to DevTools’ Sources tab, you should see an entry for the service worker in the left hand side panel as well as in the Threads category.

• The console will show you messages from the service worker.

• You can also use the console’s drop down to switch context between your document and the service worker

We are also working on exposing other service workers in DevTools (e.g. debugging lifecycle issues, debugging push scenarios), stay tuned.

[Jochen Eisinger]

On Wed, Mar 25, 2015 at 8:59 AM Kenji Baheux <kenji...@chromium.org> wrote:

Contact emails

Engineering: ksak...@chromium.org, kin...@chromium.org  

PM: kenji...@chromium.org

Spec

Editor's draft (W3C Public Working Draft)

Summary

We would like to rename clients.getAll to clients.matchAll (crbug/451334). We’ve been issuing deprecation warnings for clients.getAll and had matchAll shipped since M42.

In addition, we would like to add support for its optional ClientQueryOptions argument (crbug/460415, crbug/455241) in M43.

API level detail (relevant changes in bold)

Support for ClientQueryOptions will let developers:

• match all clients including yet to be controlled clients or just clients that are controlled

• match clients by type (e.g. window, worker, sharedworker, all)

Link to “Intent to Deprecate” thread

Note: we didn’t have an explicit intent to deprecate thread for deprecating getAll.

Motivation

For consistency, getAll has been renamed to matchAll in the spec (issue/610). We believe that we should remove getAll while adoption is still relatively low.

Usage information from UseCounter

Unfortunately, it seems that UseCounter can’t be used in a worker context. We do have an upper bound which seems reasonable though.

why is that? There are other use counters on worker related IDL fiels, e.g. RequestFileSystemWorker.

[Kenji Baheux]

Usage information from UseCounter

Unfortunately, it seems that UseCounter can’t be used in a worker context. We do have an upper bound which seems reasonable though.

why is that? There are other use counters on worker related IDL fiels, e.g. RequestFileSystemWorker.

Sorry, more precisely UseCounter only works in Dedicated Workers.

Here is the bug https://code.google.com/p/chromium/issues/detail?id=376039

[Chris Harrelson]

On Wed, Mar 25, 2015 at 12:59 AM, Kenji Baheux <kenji...@chromium.org> wrote:

Contact emails

Engineering: ksak...@chromium.org, kin...@chromium.org  

PM: kenji...@chromium.org

Spec

Editor's draft (W3C Public Working Draft)

Summary

We would like to rename clients.getAll to clients.matchAll (crbug/451334). We’ve been issuing deprecation warnings for clients.getAll and had matchAll shipped since M42.

In addition, we would like to add support for its optional ClientQueryOptions argument (crbug/460415, crbug/455241) in M43.

API level detail (relevant changes in bold)

Support for ClientQueryOptions will let developers:

• match all clients including yet to be controlled clients or just clients that are controlled

• match clients by type (e.g. window, worker, sharedworker, all)

Link to “Intent to Deprecate” thread

Note: we didn’t have an explicit intent to deprecate thread for deprecating getAll.

Motivation

For consistency, getAll has been renamed to matchAll in the spec (issue/610). We believe that we should remove getAll while adoption is still relatively low.

Usage information from UseCounter

Unfortunately, it seems that UseCounter can’t be used in a worker context. We do have an upper bound which seems reasonable though.

Could you manually convert the upper bound into a percentage based on internal data, and report that?

 

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS and Android, Android WebView)?

Yes.

Compatibility Risk

Pluses and minuses:

+ This is a relatively small change to a shipping API surface.

+ We’ve been issuing deprecation warnings about getAll in M42.

- No usage metrics because usage counter is not supported in a worker context

 + but the upper bound is reasonable.

+ Mozilla has already renamed getAll to matchAll (mozilla/1130685) in their on-going implementation of Service Worker.

Link to entry on the feature dashboard

http://www.chromestatus.com/feature/6561526227927040

Sidenotes

Update about debuggability

In M43, debugging Service Workers has become much simpler.

• Web developers will now be able to debug their controlling service worker and their website within the same devtools window.

• Head over to DevTools’ Sources tab, you should see an entry for the service worker in the left hand side panel as well as in the Threads category.

• The console will show you messages from the service worker.

• You can also use the console’s drop down to switch context between your document and the service worker

We are also working on exposing other service workers in DevTools (e.g. debugging lifecycle issues, debugging push scenarios), stay tuned.

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

[PhistucK]

To make it clearer (for me, anyway), this is really -

1. Intent to remove ServiceWorkerGlobalScope.clients.getAll()

Alternative implementation -

ServiceWorkerGlobalScope.clients.matchAll()

2. Intent to ship the ClientQueryOptions parameter of ServiceWorkerGlobalScope.clients.matchAll(...).

While "rename" sounds better, it softens the impact and I prefer to be explicit, since the code will throw an exception because of this and possibly crash the entire scripting execution.

Note that the API level change document marks as bold the wrong API (registration), still shows getAll instead of matchAll and still shows that the new parameter is not implemented. Perhaps you meant to link to a different document?

☆PhistucK

[Philip Jägenstedt]

LGTM, better to rename as soon as possible. I assume that adoption of
Service Workers is still low enough that you could simply notify the
people you know have already written libraries or deployed Web apps
using SW.

Philip

[kenji...@google.com]

On Tuesday, March 31, 2015 at 3:01:48 PM UTC+9, Philip Jägenstedt wrote:

I assume that adoption of Service Workers is still low enough that you 

could simply notify the people you know have already written libraries 

or deployed Web apps using SW.

Yes, this is indeed the case (it's still in the manageable realm but probably not for long ;).

We believe that we are in touch with all the existing and upcoming deployments.

 

Also, here is the correct API level detail document.

Thanks Phistuck!

[Chris Harrelson]

On Tue, Mar 31, 2015 at 12:50 AM, <kenji...@google.com> wrote:

On Tuesday, March 31, 2015 at 3:01:48 PM UTC+9, Philip Jägenstedt wrote:

I assume that adoption of Service Workers is still low enough that you 

could simply notify the people you know have already written libraries 

or deployed Web apps using SW.

Yes, this is indeed the case (it's still in the manageable realm but probably not for long ;).

We believe that we are in touch with all the existing and upcoming deployments.

Ok. Based on that LGTM.

 

 

Also, here is the correct API level detail document.

Thanks Phistuck!

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

[TAMURA, Kent]

LGTM3.

bit.ly/blinkintents missed this because the subject doesn't start with "Intent to ship:".

--

TAMURA Kent
Software Engineer, Google