Re: asynchrony for addStream w/ error/success callbacks

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.

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
>>
>

Received on Thursday, 16 January 2014 00:45:09 UTC