Re: peerConnection constraints webidl implementer feedback

+1, seems more clear.
El 16/10/2013 00:04, "Jan-Ivar Bruaroey" <jib@mozilla.com> escribió:

>  Hi all,
>
> Here's some feedback after cleaning up constraints for createOffer/Answer
> in PeerConnection in Firefox. They're in engineering-style bullet-points,
> so my apologies in advance for the terseness (these are all requests for
> spec changes).
>
> These are probably more controversial than the feedback I just posted for
> gUM in media-capture, so I'll jump right in:
>
>
>    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:
>        - There is no "audio" or "video" top-layer, we jump right into
>          mandatory vs. optional.
>           - 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)
>          - The mandatory algorithm boils down to "use these settings
>          (which you must support)". Very simple.
>           - 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.
>          - 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.
>
>                - 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:
>          - "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.
>
>        2. MediaStreamConstraints seems mis-named. It appears to house
>    PeerConnection-specific settings, like OfferToReceiveVideo etc. not
>    settings for MediaStreams.
>
>
> Here's what I propose we do instead for PeerConnection:
>
>
>    - Declare createOffer/Answer/addStream to take a 'Settings' *dictionary
>    *.
>       - This dictionary has *mandatory* and *optional* members like
>       today, except that optional is another dictionary not an array.
>    - Remove any mention of these being constraints (which they are not),
>    and
>       - spell out a simple "unknown mandatory settings fail (and
>       mandatory trumps optional)" algorithm.
>
> This would pretty much work with what we have already. Thoughts?
>
> .: Jan-Ivar :.
>
>