- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Wed, 20 Mar 2013 10:07:10 -0700
- To: Adam Bergkvist <adam.bergkvist@ericsson.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 20 March 2013 00:24, Adam Bergkvist <adam.bergkvist@ericsson.com> wrote: >> 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? The reason we settled on ensuring that tracks are duplicated was that we didn't want to have tweaks to one track affecting other tracks. Maybe that was the wrong decision, but I tend to think that the following is a better model: > [Source] ---> [Track] ---> [Sink] > \--> [Track] ---> [Sink] What this does is reduce the cardinality to unity at the track level. Sources and sinks still need to deal with multiple tracks, but that's natural. "1 to n" is much easier to manage than "m to n".
Received on Wednesday, 20 March 2013 17:07:38 UTC