peerConnection constraints webidl implementer feedback

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

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

 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/.
      o 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
      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?

.: Jan-Ivar :.