Re: peerConnection constraints webidl implementer feedback

On 10/16/13 11:02 AM, Harald Alvestrand wrote:
> On 10/16/2013 12:02 AM, Jan-Ivar Bruaroey wrote:
>>
>>  1. About the settings passed to createOffer/Answer & addStream:
>>     These are not really constraints IMHO!
>>       * I see constraints as defined in gUM by their /reduction/
>>         algorithm on some starting pool of similar-propertied things,
>>         candidates. Applying this model to the abstract
>>         "capabilities" of PeerConnection seems like a stretch that
>>         would need a lot of upside to justify the complexity and
>>         confusion it adds upfront (like the inverse logic, and
>>         whether these things and gUM-constraints are interchangeable)
>>       * Differences from gUM constraints:
>>           o There is no "audio" or "video" top-layer, we jump right
>>             into mandatory vs. optional.
>>           o There's no pool of similar-propertied things to reduce,
>>             so the reduction algorithm for optional constraints
>>             doesn't fit, and the array construct serves no purpose
>>             (other than that the whole category is not-mandatory)
>>           o The mandatory algorithm boils down to "use these settings
>>             (which you must support)". Very simple.
>>           o Once unknown keys have been checked for, there's no
>>             difference between mandatory and optional internally,
>>             which boils down to a flat struct of settings.
>>
> Except that if you don't know if something's supported, but you'd like 
> to have it if it's available, the optional part gives you that.

Sure. I don't distinguish between unknown and unsupported here, so when 
I say "unknown keys have been checked for", that's the step that 
validates browser support. Once that check has been made (which we do 
early), our downstream code is super-simple as there's just a single set 
of (known) settings to store and for the actual code to deal with.

>>           o OfferToReceiveVideo, OfferToReceiveAudio and
>>             VoiceActivityDetection are effectively features you turn
>>             ON in most cases, not limiters or reducers.
>>               + This manifests itself as a problem in the optional
>>                 case where it's not clear how to handle failures of
>>                 something that is "optional", does it fire the
>>                 error-callback or does it proceed without error? This
>>                 doesn't come up in gUM.
>>
>
> VoiceActivityDetection is a good example of something that might or 
> might not be present, and most applications can probably live without 
> it. If it's not implemented, the call should continue without error.

Of course. I'm not proposing we drop mandatory vs. optional, I'm 
proposing we drop the array and the pretense that PeerConnection 
settings are constraints.

>>       * The last thing I said about a request being "optional"
>>         doesn't even make sense, which is the next problem: In place
>>         of the reduction algorithm, which doesn't fit here, we/I
>>         succumb to attempts at intuiting downstream uses for the
>>         mandatory vs. optional distinction, which in itself is
>>         troubling. The big one is:
>>           o "Otional" means "Do this if you can"
>>       * But say the system runs out of ways to receive video because
>>         we are receiving 50 videos already, does this setting being
>>         specified as "optional" mean we fire the error callback or
>>         push through silently? - Regardless of your answer, you must
>>         admit you are far removed from the gUM constraints algorithm.
>>
>
> I don't really see the difference.

Then what's your answer? Should it fire the error callback or push 
through silently?

I'm looking at the difference between "not supported" and "supported, 
but it failed". Yes we should ignore "optional" requests we don't 
recognize, but for things we do support we should always call the 
error-callback on failure, is what I'm saying.

>> Here's what I propose we do instead for PeerConnection:
>>
>>   * Declare createOffer/Answer/addStream to take a 'Settings'
>>     /dictionary/.
>>       o This dictionary has /mandatory/ and /optional/ members like
>>         today, except that optional is another dictionary not an array.
>>
>
> Doesn't allow for sequencing, which is what we use for priority. Been 
> discussed many times before, no consensus to change detected.

Can you give me an example of where we would need sequencing for 
PeerConnection settings?

> In many cases, I think constraints at this level will be "yes or no" 
> things - but still, I think there's value in having a consistent 
> interface.

If I build my boat and my house the same way that's not consistent (or 
maybe it is, but one will sink or tip over).

>>   * Remove any mention of these being constraints (which they are
>>     not), and
>>       o spell out a simple "unknown mandatory settings fail (and
>>         mandatory trumps optional)" algorithm.
>>
>> This would pretty much work with what we have already. Thoughts?
>
> Sorry, been there, discussed that, ended up where we are.

Given how little is spelled out here in the spec, the opportunity to fix 
this seems here still.

s/constraint/setting/
s/MediaConstraint/RTCSettings/
s/TODO/"unknown mandatory settings fail (and mandatory trumps optional)"/

.: Jan-Ivar :.