Re: Simplify the new addTrack() API

On 02/09/2015 03:26 PM, Adam Bergkvist wrote:
> Hi
>
> With the introduction of RTCRtpSender/Receiver (Doohickeys), the way to
> send and receive media will change. We used to add a MediaStream at one
> end, and dispatch a corresponding stream at the other end.
>
> The new addTrack()-based approach is to add one MediaStreamTrack and
> zero or more MediaStreams, containing the track, at one end, and
> dispatch a RTCRtpReceiver, the corresponding track and a list of
> MediaStreams, containting the track, at the other end. This implies
> creating a new stream if a certain stream isn't represented at the other
> side, or no stream was supplied for a track, and keeping handles to
> previously created streams to be able to add future tracks to them.
>
> Even though the API call is named addTrack(), MediaStreams are very much
> involved with increased complexity as the cost. One reason for this is
> the need to polyfill the old addStream()-API on top of the new.

This is a common thing to have to do, whether it's done as part of 
implementing the spec or as part of making the spec usable for people 
who are used to the "previous style".

These days, it seems common to write new APIs first as polyfills and 
then embed the polyfill (still in Javascript) inside the browser through 
an API-embedding mechanism and call it "platform implementation" - I 
hear this is done for the Chrome Promises API, for instance.

>
> A different approach could be to keep the new addTrack()-API simple and
> provide the API points needed to polyfill or implement advanced stream
> handling in the application. For example:
>
> addTrack(MST track, optional DOMString tag);
>
> - The optional tag argument is a string that is signalled in SDP that
> contains application specific info. For example, a list of MediaStream
> ids.

I take it you're assuming that the app would have to know from 
non-standard sources what the tag was supposed to mean?

If it's going to support the previous addStream() API in the way the 
currently proposed addTrack() does, with multiple streams created, it 
would have to be either a sequence of DOMStrings or a tag with internal 
syntax <ugh>.

>   The corresponding event would expose the string the other side.
>
> (Constructor) MediaStream(DOMString id);
>
> - Construct a stream with a given id.
>
> Feedback and suggestions are welcome.

As an experiment, I'd suggest writing up the polyfill that would give 
the old addstream API on top of the proposed API and see where the 
disconnects (if any) are.

>
> /Adam
>

Received on Tuesday, 10 February 2015 07:07:04 UTC