Re: replaceTrack proposal

On 3 September 2014 13:03, Bernard Aboba <Bernard.Aboba@microsoft.com> wrote:
> With respect to the success/failure callbacks, I am wondering whether most of the potential errors wouldn't be handled via an Exception, rather than requiring a failure callback.  Also, I'd expect that setTrack would return quickly so that async behavior isn't an absolute requirement.   Or am I missing something that requires async behavior?

Some checks (that both are audio, that both have identical
peerIdentity constraints, that both are in the right state) are
trivial and wouldn't require a dispatch.

However, in our implementation, it's likely that confirming that a
track is a compatible replacement could require asynchronous
dispatches to a separate thread.  Blocking the main processing thread
for a synchronous dispatch would be very bad.  In general, I'd prefer
to have things that need to look at media be asynchronous to avoid any
risk that a synchronous dispatch is needed.