Re: asynchrony for addStream w/ error/success callbacks

On Wed, Jan 15, 2014 at 4:44 PM, Martin Thomson <martin.thomson@gmail.com>wrote:

> I'll point out the commented text in the specification regarding
> addStream and constraints:
>
>               <!--li>
>                 <p>Parse the <var>constraints</var> provided by the
> application
>                 and apply them to the MediaStream, if possible. If the
>                 constraints could not be successfully applied, the user
> agent
>                 MUST queue a task to invoke <var>failureCallback</var>
> with a
>                 <code>DOMError</code> object whose <code>name</code>
> attribute
>                 has the value
> <code>IncompatibleConstraintsError</code>.</p>
>               </li>
>
>               <li>
>                 <p>If the stream has a <var>peerIdentity</var> constraint
>                 set and the <code><a>RTCPeerConnection</a></code> is in a
>                 connected state, check that the remote identity matches the
>                 constraint. If there is no match,  the user agent MUST
> queue a
>                 task to invoke <var>failureCallback</var> with a
>                 <code>DOMError</code> object whose <code>name</code>
> attribute
>                 has the value
> <code>IncompatibleConstraintsError</code>.</p>
>                 </p>
>
>           <p> TODO - need to add a failureCallback for this to do
>               above. </p>
>
>               </li-->
>
> Both create situations where failures would need to be suppressed and
> triggered on setXXXDescription.
>
> I'm not really hard over on this issue, but what is clear to me is
> that the usage model sucks if we defer errors.
>
> If we intend to keep the "add to cart, checkout" model for addStream,
> then we should consider removing constraints from that function.  A
> simple add with deferred consequences is one thing, but having to deal
> with constraint failures is going to generate significant pain.
>

Yes - I already assumed we would relegate those constraints to the dustbin,
preferring the use of doohickeys instead.

>
> On 14 January 2014 11:33, Justin Uberti <juberti@google.com> wrote:
> > I agree with Stefan. Hardware encoders typically are limited by pixel
> rate
> > as opposed to just a number of streams, so a successful AddStream is no
> > guarantee of success (or vice versa) when we allow constraints on the
> > track/doohickey to be mutated later.
> >
> > Ergo, I think we should keep AddStream/Track with the "add-to-cart"
> > semantics mentioned by Jan-Ivar.
> >
> >
> > On Sat, Jan 11, 2014 at 5:12 AM, Stefan Håkansson LK
> > <stefan.lk.hakansson@ericsson.com> wrote:
> >>
> >> On 2014-01-10 18:38, Martin Thomson wrote:
> >> > On 10 January 2014 01:13, Stefan Håkansson LK
> >> > <stefan.lk.hakansson@ericsson.com> wrote:
> >> >> I may be wrong...
> >> > :)
> >> >
> >> > I was planning to propose a change to the API that would necessitate
> >> > an error on addStream.  More on that later, it requires a better
> >> > explanation than I want to hide on this thread.
> >>
> >> Looking forward to it (and I sort of hope it will be addTrack rather
> >> than addStream)!
> >>
> >> But, without going into details, the current discussion seems to evolve
> >> around when the check of whether or not there are resources available to
> >> actually transmit the tracks of the added stream or not is carried out
> >> at addStream time, or later (createOffer); and how the application gets
> >> to know about that a track can not be sent (is it at addStream, by an
> >> event fired on the DooHickey, or by polling the stats API).
> >>
> >> I am fine with any way - but it is clear we need to agree.
> >>
> >> And I would argue that having that error at addStream is not that
> >> helpful, because things can change later. Say you addStream, and then
> >> add one more track to the MediaStream (this was really another argument
> >> why we should addTrack rather than addStream to PeerConnection). Or say
> >> you change resolution and framerate on a track being sent by working
> >> with the Constraints of that track, and now the PeerConnection can't
> >> handle it any more. And some people have been pointing out the CPU clock
> >> may be lowered in frequency due to overheating at any time.
> >>
> >> Stefan
> >>
> >
>