search

w3c / web-locks

Cross-tab resource coordination API
https://w3c.github.io/web-locks/
Other
124 stars 16 forks source link

Should mode be optional? #3

Closed inexorabletash closed 7 years ago

inexorabletash commented 7 years ago

Right now the API requires both scope and mode to be specified as arguments. Should we default mode to "exclusive"and move it into the options bag?

domenic commented 7 years ago

If we are OK picking a default, it could be a boolean (either shared: true or exclusive: true). Assuming we don't anticipate more than two modes.

I'm not sure I fully understand this property though (having read the README paragraph and not the linked Wikipedia article) so I should probably do so before answering the actual question.

jakearchibald commented 7 years ago

The idea is that write transactions generally need to have an "exclusive" lock, so nothing else can read and write at the same time. Whereas read transactions can happen concurrently with other read transactions, so they're "shared".

{exclusive: true} as an optional 2nd arg sounds good to me, where exclusive defaults to false.

inexorabletash commented 7 years ago

Making exclusive optional/default=false seems weird to me. If every call used that setting, the API would be a no-op. If you're thinking about using this API to implement a "mutex" then exclusive is the only setting you'd want, never shared.

I guess I'd argue for keeping the mode it as-is (non-optional) since it makes the developer reason about the behavior they want. I'd be okay with {shared:true}.

jakearchibald commented 7 years ago

In IDB "read" is the default, which is why I went for "shared" default, but you're right.