W3C

- DRAFT -

Media Capture Task Force F2F

21 May 2014

Agenda

See also: IRC log

Attendees

HTA, StefanH, Adambe, Giri, AdamR, JIB, EKR, Martin, pthatcher, Juberti, shijun, bernard, Fluffy, burn, JimB, AlexGouaillard, Dom, TedHardie, UweRauschenbach, AndrewH, DanDruta, Suhas, DiniMartini, Jesup (remote), Lagerway (remote)
Observers
MaryBarnes, RomanShpount, Jonathan Lennox (remote), Tzabari Gili (remote)
Regrets
Chair
hta, stefanh
Scribe
dom

Contents


<trackbot> Date: 21 May 2014

<stefanh> The same recording session and hangout as rtcweb will be used

<scribe> scribe: dom

<scribe> scribenick: dom

constraints (bis repetita placent)

Peter's slides

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]

update to constraint syntax promise

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]

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.138 (CVS log)
$Date: 2014-05-27 12:23:48 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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]