WorkletId: why not based on a pipeline-namespace

[gterzian]

What is the reason for the worklet id being a random number, versus something based on a PipelineNamespace like PipelineId and so on?

servo/components/msg/constellation_msg.rs

Line 36 in a8ae0e5

pub struct PipelineNamespace {

servo/components/script/dom/worklet.rs

Line 168 in 03f2236

pub struct WorkletId(Uuid);

One reason I can think of making the Id something in msg, is that we might want to share those Ids outside of script, for example to directly route input event from the compositor to a work(let)er thread, which is something I saw discussed in Chromium and I think is a pretty interesting idea, see https://docs.google.com/document/d/1Ah3-O7Emp7cURyh-TINME0fId9laU0ctMCwjmlArgqU/edit#heading=h.182sjzemmty4

More generally, I think the idea of unifying all Ids into msg and based on PipelineNamespace(unless they absolutely must be random), and planning for sharing stuff outside of script/content-process, since it makes certain cross-process/event-loop coordination easier, is a worthy endeavor. See for example the ongoing work with Messageport, which requires the constellation to be aware of both MessagePortId and MessagePortRouterId.

There is also ongoing work that makes it easier to install a pipeline-namespace in any threads(for example the worklet threadpool), see #23934

cc @asajeffrey

[asajeffrey]

It's more the other way round, why are we using our own ad hoc implementation of a uuid when there exists an off-the-shelf one? The answer is size, a pipeline is is 64 bits, and a uuid is (IIRC) 128.

So in case where id size doesn't matter that much, I'd rather use the standard solution, but this is more a matter of taste than anything.

[gterzian]

Ok, thanks for pointing that out, I wasn't aware of the difference.

Could there be additional benefits in putting all UUIDs(regardless of how they are generated) in the msg crate? It could increase coherency and make them by default shareable with other crates, like the constellation(potential use-case for that mentioned above).

[asajeffrey]

Yeah, we could make the IDs consistent, there's no great reason for worklets being different.

[gterzian]

Ok closing this, I don't think it's super actionable, using a UUID for the worklet id seems appropriate at this stage.