Re: ReplaceTrack vs RTPSender.track = new

In the work in the ORTC CG, we chose to make it a method
(.setTrack(newTrack)) rather than a writable attribute (.track =
newTrack).  In fact, we choose to follow the .setFoo pattern rather than
the .foo= for all things, not just setTrack for the following reasons:

1.  It allows return values, async and sync.  You might think you don't
want one now, but you might want to add one later.
2.  It allows async errors.
3.  It allows for adding additional parameters.  You might think you don't
want one now, but you might want to add one later.

For those reasons, I also prefer .replaceTrack over setting .track.


I also have thoughts over the rest of you error conditions and what we
should do about them, but I think that's secondary and will leave that
discussion for another time :).

On Wed, Apr 15, 2015 at 12:31 AM, Harald Alvestrand <harald@alvestrand.no>
wrote:

> In mulling over this issue, I've been thinking about failure cases, and
> about negotiated constraints.
>
> Consider this case:
>
> A negotiates with B to send video
> The agreeed capabilities for B is 320x200 max (it's a doorbell, I guess).
> A sends a track to B with 320x200 format.
>
> A does ReplaceTrack with a HD track (currently also being displayed in HD
> somewhere else).
>
> Three possibilities:
>
> - A downsamples to 320x200 as (conceptuaully) an internal function of the
> PeerConnection
> - A treats B's restrictions as (new) constraints on the track, and all
> other users switch to 320x200
> - ReplaceTrack fails
>
> Replay the same case where the source of the new track is a VP8-only
> camera, and B says it can only take H.264 (I guess it's a gateway).
>
> Three possibilities:
>
> - A transcodes the video internally to PeerConnection
> - A inserts transcoding at the source
> - ReplaceTrack fails
>
> And of course the weird one:
>
> A does ReplaceTrack, trying to replace an audio track with a video track.
>
> ANALYSIS:
>
> If ReplaceTrack never fails, all possible scenarios must be handled with
> successful outcomes. That seems like a tall order.
>
> If ReplaceTrack can sometimes fail, and we can always report the error
> synchronously in an exception (IllegalParameter for the last one, I guess),
> the two solutions are equivalent.
>
> If ReplaceTrack can sometimes fail, and we don't want exceptions to be
> thrown (for instance, we might not be able to instantly decide whether the
> replacement is possible or not), ReplaceTrack() is superior.
>
>
>
>