Intent to prototype: Web Locks

[Kagami Rosylight]

Web Locks introduces a way to coordinate the usage of resources across tabs, workers, etc.

navigator.request.lock("foo", async lock => {
  // "foo" is locked until this callback ends
});

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1666833
Standard: https://wicg.github.io/web-locks/
Platform coverage: All
Preference: dom.weblocks.enabled (will be disabled by default on Nightly until key features are covered)
Other browsers:

• Chrome: shipped since version 69
• Safari:  no public sign yet (https://github.com/WICG/web-locks/issues/55#issuecomment-553257387)

web-platform-tests: https://wpt.live/web-locks/

[Tantek Çelik]

On Mon, Aug 16, 2021 at 3:19 PM Kagami Rosylight <krosy...@mozilla.com> wrote:
>
> Web Locks introduces a way to coordinate the usage of resources across tabs, workers, etc.
>
> navigator.request.lock("foo", async lock => {
> // "foo" is locked until this callback ends
> });

Thanks Kagami.

+1 to prototyping this.

> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1666833
> Standard: https://wicg.github.io/web-locks/
> Platform coverage: All
> Preference: dom.weblocks.enabled (will be disabled by default on Nightly until key features are covered)
> Other browsers:
>
> Chrome: shipped since version 69
> Safari: no public sign yet (https://github.com/WICG/web-locks/issues/55#issuecomment-553257387)

The combination of:
* only one other browser having implemented this
* that browser having already (prematurely IMO) exposed this to the
open web ("shipped")
* the "standard" is only a WICG draft (a proposal, not actually a standard)
is quite concerning.

None of those should stop us from prototyping, to be clear.

However, since we are the second browser to show interest, that means
we should at least raise (perhaps drive) the need for the spec to move
from WICG to an actual standards group, (WHATWG, WebApps WG, etc.).

The good news is that the WebApps WG charter is currently up for
renewal, and Web Locks is at least already in the "WICG
specifications" section:

https://www.w3.org/2021/08/webapps-charter-2021.html#wicgspecs

Since this thread publicly expresses our intent for Web Locks, as the
second browser to show interest, we should ask for Web Locks to be
moved to the "Normative Specifications" section of the proposed
charter:

https://www.w3.org/2021/08/webapps-charter-2021.html#normative


Kagami,

Can you file an issue in the Web Apps repo:
https://github.com/w3c/webappswg/issues
requesting that Web Locks be moved from the "WICG specifications"
section to the "Normative Specifications" section of the proposed
charter?

Feel free to cite this email thread as context, and cc: GitHub @tantek.

Thanks,

Tantek

P.S. This case has highlighted some aspects of our Intent process[1]
that could be more explicit to better handle when situations like this
occur, and to actively help move things along in the standardization
process. I'll start a separate discussion on that.
[1] https://wiki.mozilla.org/ExposureGuidelines

>
> web-platform-tests: https://wpt.live/web-locks/
>
> --
> You received this message because you are subscribed to the Google Groups "dev-pl...@mozilla.org" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to dev-platform...@mozilla.org.
> To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-platform/a283caa1-8ca5-4053-b3eb-ea0624d142aen%40mozilla.org.

[Kagami Rosylight]

Hi Tantek,

Thank you for catching it, and done as you requested: https://github.com/w3c/webappswg/issues/73

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