- From: Adam Bergkvist <adam.bergkvist@ericsson.com>
- Date: Wed, 20 Mar 2013 08:24:45 +0100
- To: Martin Thomson <martin.thomson@gmail.com>
- CC: Jim Barnett <Jim.Barnett@genesyslab.com>, Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>, "public-media-capture@w3.org" <public-media-capture@w3.org>
On 2013-03-19 16:57, Martin Thomson wrote:
> Maybe an explicit .clone() is the right answer, with one additional wrinkle:
>
> Throw an exception if a track is already attached to a sink.
>
> Then we can enforce a strict 1 source, 1 track, 1 sink cardinality
> without strange and opaque behaviour. Each track could have a 'sink'
> attribute that exposes any existing attachment so that this limitation
> is discoverable. You can add text to the exception that recommends
> .clone()-ing.
Can you be more specific about the strange and opaque behavior?
I see a track as an instance of a control surface for a source used to,
e.g., mute/unmute and direct the source output to a sink. I don't see a
clear reason why we should limit how many sinks a track can direct its
output to.
[Source] ---> [Track] ---> [Sink]
\--> [Sink]
Two sinks rendering data from a source with the same control surface.
[Source] ---> [Track] ---> [Sink]
\--> [Track] ---> [Sink]
Two sinks rendering data from a source with different control surfaces.
/Adam
Received on Wednesday, 20 March 2013 07:25:08 UTC