What is the order of events being track clones?

[youennf]

Track clones will all fire events when being ended, muted...
The order of the events is visible from web applications but the spec is not really clear about this.

It even allows one track to be muted and not a clone, since UA can set muted on a track granularity and not source granularity.

I would think this has no bing interop impact but the spec should in theory provide guidance there since this is JS observable (maybe fire events by order of creation of tracks?)

[eladalon1983]

I would think this has no bing interop impact but the spec should in theory provide guidance there since this is JS observable (maybe fire events by order of creation of tracks?)

Order of creation might not be deterministic if tracks are transferable to a worker and back, and clones are produced simultaneously in both the worker and the window.

Tracks, their clones and clones-of-clones all form a tree with the original track as the root. Maybe:

• The order could be some specific traversal of that tree when all tracks are involved.
• The order can be a specific node only when the UA mutes just a specific track.

[youennf]

Order of creation might not be deterministic if tracks are transferable to a worker and back

Order should ideally be deterministic within a context (window or worker).
We cannot guarantee the order of an event fired in a window and another event fired in a worker.

• The order could be some specific traversal of that tree when all tracks are involved.

Yes, as said above, one order is by creation time (this would make getUserMedia initial tracks to be first, and then the cloned (or transferred back) tracks. This guarantees that all tracks of a context are ordered deterministically.

• The order can be a specific node only when the UA mutes just a specific track.

I'd like to move away from this single track mute approach.
Muted is a state of the source and should apply to all tracks of the same source.
Ideally, the spec would say something like the following: when UA detects that a source gets muted, get the ordered list of tracks associated to the source and iterate through the list to queue a task to fire the mute event.

[eladalon1983]

I was pointing out something different.

• Start with t1 in Window.
• Clone it as t2.
• Post it to a Worker.
• Clone t1 (in Window) as t3.
• Clone t2 (in Worker) as t4.
• Post both t2 and t4 back to Window.
• Fire an event.

As I mention here, "order of creation" is unclear between t3 and t4, which were cloned concurrently.
But tree-traversal, possibly BFS, could impose a reasonable order here. (With some arbitrary property like deviceId-lexicographic-order used for breaking ties between same-level children.)

[youennf]

I do not think this matters, t3 and t4 being in different contexts, we do not need a strong order.
At time of creating t3 and t4, the order would be t1, t3 and t2, t4 (though it is not really t2 but t2b given transferring creates a new track).

When posting back to window t2 and t4, the creation order could be t1, t3, t2bb, t4b (provided postMessage is called using transfer = [t2b, t4]and we agree with ordering accordingtransfer`).

[eladalon1983]

I do not think this matters, t3 and t4 being in different contexts, we do not need a strong order.

Note that my example includes posting t3 back so that it IS in fact in the same context as t4 by the time the event fires.

If we transfer when posting, what order do we want to use?