Lock vs LockInfo

[ralphch0]

According to the spec the request() method returns a Lock object, while the query() method returns LockInfo objects. The only difference is the clientId field.
https://inexorabletash.github.io/web-locks/#api-lock-manager

Is there are reason why we have this differentiation?

[inexorabletash]

LockInfo is a dictionary because it's a pure information dump. Lock is an interface because I imagine adding more capabilities in the future, e.g. event for when it is released, waitUntil, etc.

I agree there's no reason to have Lock be an interface now, but it's hard to change later.

[ralphch0]

Makes sense. Any reason clientId shouldn't also be on the Lock object.

[inexorabletash]

It's not really beneficial now since any given script is going to get locks corresponding to its own context. If we expose the environment id as e.g. window.environmentId, then that would be the same for all locks visible to a script. (Unless there are cross-window hijinks.)

[ralphch0]

I guess the issue is that today the current clientId is not easily accessible by pages. Ideally we'd like the entire Clients API to be accessible from any page and also expose the current page client id.
In any case, I think this is fine for now since query() can be used while the lock is held to figure out the page's current id. Since clientId is becoming the defacto standard page identifier, it would be nice to have more accessible APIs in the near future.

[inexorabletash]

Can you comment on whatwg/html#3378 perchance?

Specifically, data that "... clientId is becoming the defacto standard page identifier ..." would help us prioritize getting it exposed everywhere.

[inexorabletash]

Per offline discussion, we should push on exposing it globally rather than having web apps "abuse" locks to determine the page's id.