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