See also: IRC log
<trackbot> Date: 21 May 2014
<stefanh> The same recording session and hangout as rtcweb will be used
<scribe> scribe: dom
<scribe> scribenick: dom
HTA: Peter will present a new compromise proposal on everyone's favorite topic, constraints
Peter: this is about the
constraints syntax
... we were stuck on Monday on some disagreement
... so got to talk to a lot of people to under the real
issue
... which turned out to be the list of required properties at
the top of the constraints object
... so tried to look into how to get rid of it
... first, looking at why we have it in the first place
... which ties to WebIDL requirements combined with the "must
fail on unknown mandatory constraints"
... 3 options: toss WebIDL, hack around it (current), use JS to
check what's supported
... [showing before / after example illustrating new
proposal]
... pros: prettier, no fiddling around required but unspecified
constraint
... cons: JS developers might be surprise of not getting
failure on stuff marked as "required: true" if they didn't
check the constraint is recognized
... all the people I've asked were happy with this
proposal
... would like to see if we have broader consensus of the
TF
gmandyam: looking at the after
example
... {video:true} would still be possible?
JimB: yes
burn: correct
... this is looking only at how this differs from the current
draft
dom: why a static method rather than a static property for supported constraints?
peter: you can't have a dictionary as an object property
dom: oh right. Good work, thanks!
JIB: I support this
proposal
... JS developers get more info this way than they had before,
so they have more choice
martin: getSupportedConstraints — why is that dictionary?
peter: it's simpler to check a dictionary, and makes it easier to extend
martin: you could use an
interface to avoid that issue
... Another question is how do you distinguish constraints
linked to audio and video?
Cullen: this is about what the browser understands (and thus can fail on it), not what the browser will successfully negotiate
hta: kind of orthogonal to this — MST.getSupportedConstraints reminds me of a discussion on a navigator.managedDevices — should we move it there.
gmandyam: having it on MST, does it mean you need to have an MST to get access to this?
Many: no
HTA: the name exists independently of instances
juberti: I would prefer avoid static method as well; a hook on a devicemanager would be better
cullen: this solves the issue I had with the earlier proposal. Thank you
hta: let's see if we have rough consensus in the room
<gmandyam> Note from my end: it looks like getSupportedConstraints() is part of the MST prototype. That was not clearly expressed as part of the proposal.
hta: alternatives I'm suggesting:
1. peter (or someone) comes up with a carefully written up
change proposal; 2. let's not do this change
... we have consensus on alternative 1
... in the room
stefanh: when can we have a proposal?
peter: in a couple of weeks?
hta: June 7 then
gmandyam: I suggest we remove the existing text with its advanced stuff
hta: we haven't discussed (let
alone agreed) such a change
... advanced is the equivalent of what we have had as
"optional" before
gmandyam: if we want to document baseline consensus in the spec, "advanced" shouldn't be in there
cullen: we could have a consensus call on "current + getSupportedConstraints + ideal"
peter: have additional
proposals
... we could make "required: true" the default
... to avoid the "do what I said" flag
... and as I'll show this plays nicely with "ideal"
... if we have "required" the default, then adding "ideal" to
mark something as optional (in addition to using
"advanced")
... this leads to the notion of defining "ideal" in terms of
"advanced"
... this forms a consistent additional proposal that we could
discuss as a direction
martin: I wonder if "ideal" could
be the default instead of "required"
... where "width:640" would be "width:{ideal:640}"
peter: the idea of making "required" the default is that this reduces the surprise for developers
adambe: I'm with martin on this — we should make "strictness" harder to get to
juberti: likewise; failures
should be the exception
... would still want to be able to set "ideal" in addition to
"min" / "max"
martin: looking at the "do what I
said flag" example
... if you don't get 640x480 when asking for it, the browser
had good reasons not to
... I think "required" should default to true, but the bare
number should be "ideal"
peter: how does it apply to enum values?
cullen: the same
martin: doesn't work
... a possible way would be have e.g. "required":"front"
JimB: in enumerated cases, there are cases where you would want a range of required acceptable values, with one preferred
hta: we're now in design mode, I
don't like that
... a year ago or so, we discussed making required harder to
use
... and making it the default doesn't do this
... I'm sceptical
... it's attractive that min and max are hard limits
... and the simple way is "ideal"
... but this starts to be complicated; let's make simple things
simple, harder things possible
... this is confusing me, so it will be even more confusing to
others
... failing because e.g. one of the dimension is not what you
exactly asked for seems wrong
... we should take a soft approach by default
peter: martin's proposal would solve this
adamr: I agree that we don't want
hard limits to be surprising
... I wonder if having "exact" would usefully replace
"required"
... with the value the developer actually wants
JIB: originally I was also
against falling by default
... we have removed a major footgun though
... and the simplification of syntax is beneficial
... I'm not sold on the meaning of the bare value as
"ideal"
peter: 2 different topics: getting rid of "required:true", and the meaning of the bare number
cullen: we should not forget
about the strings in our designs
... AdamR's "exact" sounds good for that
burn: +1
... at this point, it's worth sending another proposal with
s/value/exact/ and with bare numbers meaning "ideal"
... we seem to be getting close to consensus
martin: requiring wrapping within
an object for anything that is strict seems the right thing to
do
... while keeping the "ideal" label
... let's do that
... it's urgent
burn: I think we're managing to
get through some of the hard ramifications (hopefully)
... we haven't looked at the exact semantics of "ideal"
cullen: if we can have a written up proposal of this discussion for rough consensus estimate after lunch, would be great
hta: so Peter has agreed to do
so
... giri raised an issue about "advanced", suggesting its
removal
... its basic purpose is to tell the browsers what is the most
important
martin: there are cases where you have co-dependent variables and you need a way to specify a fallback path for alternatives
JimB: advanced ties variables,
and defines a backoff strategy
... it is intended for high-end entreprise software where
developers want a great deal of control
gmandyam: I read through the spec, one of its annoying aspects is that in absence of required constraints, the algorithm doesn't impose anything to the browser
cullen: I and the other editors don't believe this is true
JimB: if the browser can satisfy a rule, it must; if it can't, it won't fail
gmandyam: I think this introduces a lot of complexity without clear use cases
JimB: we have just reiterated the use cases
stefanh: we have had this functionality in the spec for ever as "optional"
gmandyam: I think I don't like the algorithm; I'm waiting for feedback to my email on what I don't like
hta: verifying the consensus of
the group: 2 options
... raise your hand if you're OK with leaving "advanced in"
roughly as is
... raise your hand if you're not OK
<jesup> happy with leaving it in
hta: rough consensus to leave it in
[adjourning MediaCap]
<hta> everyone please move over to #webrtc - that's where the next session will be scribed
[unadjourning mediacap for a little bit]
Peter: we heard that "required:
true" be removed
... "min", "max", "exact" are required
... "ideal" implied by bare number
... "ideal" means not required
... as proposed changes beyond baseline consensus
... [before/after example]
ekr: how do I say that something is required?
peter: "exact" for enumerated values
ekr: I can't have min/max as optional stuff?
martin: you'd have to use advanced
ekr: so min/max/exact are now
hard requirements?
... this seems pretty baffling
JimB: when does "ideal" apply vs "advanced", "required"?
peter: as in the current algorithm
ekr: "exact" for a floating number hurts me
juberti: likewise; we can find a better name
jib: so for numerical values, min=max is equivalent to setting exact?
jubert: notions of "framerate" and "exact" aren't really logically compatible
ekr: the difference between ranges and enumerated values and their implication between hard and soft requirements are a recipe for disaster
cullen: is it that you don't want to use bare numbers?
ekr: I don't want different
semantics for ranges and @@@
... mixing soft/hard values is bad
... I want things to be clearly labeld as soft or hard req
jib: I agree with ekr that the
mix is a bit confusing
... if we had the default to be required, then ideal would be
the marker for soft
ekr: I want things to be clearly marked as hard/soft
burn: when it's in a structure,
it's hard
... when it's not, it's soft
... with the only exception of "ideal"
<Cow_woC> Hi
jubert: naked values are
shorthand for ideal=x
... everything is mandatory, except obviously for ideal
<Cow_woC> Who is currently speaking?
<Cow_woC> Is it Martin?
<gmandyam> ekr is speaking
<Cow_woC> ekr = Eric?
ekr: aspect ratio has to be expressible as two values
<gmandyam> ekr = Eric Rescorla (Mozilla)
<Cow_woC> Got it. Thanks.
ekr: how do you add a structured value in this model? this is what you would need for aspect ratio
<Cow_woC> dom: For future reference, https://www.w3.org/wiki/May_19_2014 should mention the channel name. I went to #webrtc by mistake.
jib: the point is this model will only work for bare numbers
cullen: on any on these examples,
you can change numbers with a structure
... this is orthogonal to the problem at hand
... removing the short form doesn't seem an improvement to
me
gmandyam: I'm ok with this
structure interpreting min/max as required
... the current spec has 3 examples; I would suggest expanding
these to clearly explain the model
<Cow_woC> MaryB: Is it possible to q+ from IRC and speak over Hangout and have them hear me remotely?
stefanh: I'm also OK with it; we can consider removing the shorthand if it creates too confusion
<Cow_woC> Lagerway: welcome
Shijun: if we move something to "advanced"; what is the impact?
peter: nothing in "advanced" is ever required
Shijun: how would this work "unknown" facing mode?
peter: however it works in the current model
cullen: I don't know if we have something for that
ekr: this is repulsive, but I don't care
<Cow_woC> FYI, Cow_woC is "Gili"
Cow_woC: I have 2 concerns with
the current proposal
... it requires us to learn a whole new language just for the
sake of getting it to work
... just using a JavaScript APi would be simpler
<scribe> ... unknown constraints will be ignored by the browser and will fire the success callback
hta: for unknown constraints, you can check via the previously-agreed method to get the list of known constraints
Gili: ok; still, I don't find the syntax very intuitive, and I don't see the benefits of using that syntax
hta: we have an existing
consensus on using constraints as the mechanism
... we're not revisiting this
... let's try to see if there is rough consensus to switch to
what has been presented
<Lagerway> hand up
hta: [everybody raise their hands in support]
<Cow_woC> My hand went up against the new proposal.
<Cow_woC> (not for)
<Lagerway> err no, not speaker queue, was in favor of last vote
<Lagerway> hand down
[Gili expresses his rejection of this proposal]
<Cow_woC> dom: thanks
<MaryB> Gili - yesterday if I'm remembering properly.
[MediaCap TF ajourned for real we swear this time]
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/Teleconference/F2F/ Succeeded: s/happy/OK/ Succeeded: s/happy/OK/ Succeeded: s/labeld/labeld/ Found Scribe: dom Inferring ScribeNick: dom Found ScribeNick: dom WARNING: No "Present: ... " found! Possibly Present: Cow_woC Dini Gili JimB JonathanLennox Lagerway Many MaryB Ted_ Travis adambe adamr burn burn_ cullen dom ekr fluffy gmandyam hta jesup jib joined jubert juberti lgombos martin mediacap peter richt scribenick stefanh trackbot You can indicate people for the Present list like this: <dbooth> Present: dbooth jonathan mary <dbooth> Present+ amy Agenda: https://www.w3.org/wiki/May_19_2014 Found Date: 21 May 2014 Guessing minutes URL: http://www.w3.org/2014/05/21-mediacap-minutes.html People with action items:[End of scribe.perl diagnostic output]