14:54:00 <RRSAgent> RRSAgent has joined #mediacap
14:54:00 <RRSAgent> logging to http://www.w3.org/2014/06/25-mediacap-irc
14:54:02 <trackbot> RRSAgent, make logs public
14:54:02 <Zakim> Zakim has joined #mediacap
14:54:04 <trackbot> Zakim, this will be MCAP
14:54:04 <Zakim> ok, trackbot; I see UW_MdCap()11:00AM scheduled to start in 6 minutes
14:54:05 <trackbot> Meeting: Media Capture Task Force Teleconference
14:54:05 <trackbot> Date: 25 June 2014
14:56:41 <ShijunSun> ShijunSun has joined #mediacap
14:57:07 <Zakim> UW_MdCap()11:00AM has now started
14:57:14 <Zakim> +Dan_Burnett
14:57:21 <burn> zakim, I am Dan_Burnett
14:57:21 <Zakim> ok, burn, I now associate you with Dan_Burnett
14:57:38 <jib> jib has joined #mediacap
14:57:42 <Zakim> +[Microsoft]
14:58:42 <fjh> zakim, code?
14:58:42 <Zakim> the conference code is 6227 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), fjh
14:58:52 <Zakim> +[IPcaller]
14:58:56 <fjh> zakim, ipcaller is me
14:58:56 <Zakim> +fjh; got it
14:58:59 <gmandyam> gmandyam has joined #mediacap
14:59:49 <Zakim> +stefanh
15:00:06 <Zakim> -stefanh
15:00:08 <fjh> Present+ Frederick_Hirsch
15:00:34 <Zakim> +gmandyam
15:00:40 <Zakim> +stefanh
15:00:51 <dom> Zakim, code?
15:00:51 <Zakim> the conference code is 6227 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), dom
15:01:04 <Zakim> + +1.267.934.aaaa
15:01:10 <Zakim> +??P9
15:01:12 <jib> zakim, aaaa is me
15:01:12 <Zakim> +jib; got it
15:01:18 <dom> Zakim, ??P9 is me
15:01:18 <Zakim> +dom; got it
15:02:24 <fluffy> fluffy has joined #mediacap
15:02:33 <adambe> adambe has joined #mediacap
15:02:47 <Zakim> + +46.1.07.14.aabb
15:02:49 <Zakim> + +1.403.244.aacc
15:03:02 <dom> Zakim, aabb is adambe
15:03:02 <Zakim> +adambe; got it
15:03:18 <fluffy> Zakim, aacc is fluffy
15:03:18 <Zakim> +fluffy; got it
15:04:06 <dom> Zakim, who's on the call?
15:04:06 <Zakim> On the phone I see Dan_Burnett, [Microsoft], fjh, gmandyam, stefanh, jib, dom, adambe, fluffy
15:04:10 <Cow_woC> Cow_woC has joined #mediacap
15:04:21 <stefanh> draft agenda: http://lists.w3.org/Archives/Public/public-media-capture/2014Jun/0118.html
15:04:44 <dom> Agenda: http://lists.w3.org/Archives/Public/public-media-capture/2014Jun/0118.html
15:04:47 <dom> Chair: hta, stefanh
15:05:20 <ShijunSun> zakim, I am [Microsoft]
15:05:20 <Zakim> ok, ShijunSun, I now associate you with [Microsoft]
15:06:24 <Zakim> + +47.41.44.aadd
15:06:53 <dom> Zakim, aadd is probably hta
15:06:53 <Zakim> +hta?; got it
15:06:57 <hta> hta has joined #mediacap
15:07:29 <Jim_Barnett> Jim_Barnett has joined #mediacap
15:08:01 <dom> fluffy: I would like to note for the record we have very few people here to make decisions, we should be careful
15:08:15 <dom> hta: W3C doesn't impose mailing list decisions the same way the IETF does
15:08:28 <dom> ... we have to make decisions, and we'll notify the list
15:08:40 <dom> fluffy: I object to make decisions given the current attendance
15:09:04 <dom> burn: hta is correct that we're entitled to make decisions given advance notice given etc
15:09:24 <lgombos> lgombos has joined #mediacap
15:09:37 <dom> ... but indeed, we're not many here, and the chairs might want to open some (potentially contentious) decisions on a case by case basis to the list
15:09:42 <fjh> you could send a Call for Consensus, CfC on the list, after rough agreement on the call
15:09:56 <fjh> q+
15:10:25 <dom> Frederick: note that we can reach rough decision on the call, and follow with mail-based call for consensus
15:11:20 <dom> Topic: Approve minutes from last meeting
15:11:22 <stefanh> http://lists.w3.org/Archives/Public/public-media-capture/2014May/0264.html
15:11:45 <dom> RESOLVED: http://lists.w3.org/Archives/Public/public-media-capture/2014May/0264.html approved as minutes
15:11:55 <dom> Topic: "Ideal" algorithm
15:12:05 <fjh> q-
15:12:11 <dom> Stefanh: let's plan on 20-30 minutes on this topic
15:12:13 <jib> https://docs.google.com/presentation/d/1jTz3pfEmgXn3y6Mk-s2SZaq3wa0VBEI7QnTR05JVR3s/edit?usp=sharing
15:12:45 <dom> jib: several options on the meaning of "ideal"
15:12:52 <dom> ... a pure hint
15:13:08 <dom> ... a fully algorithmically defined feature
15:13:20 <dom> ... a shortcut for a set of "advanced" constraints
15:13:44 <dom> ... 1 and 2 are not very appealing to me
15:13:56 <dom> ... I have a "minimum" algorithm proposal for 3
15:14:51 <hta> q?
15:14:58 <dom> ... [reading from slide]
15:15:15 <burn> q+
15:15:23 <dom> hta: could you give more details on not providing new functionality?
15:15:30 <dom> jib: dan was concerned about testability
15:15:35 <burn> q-
15:16:03 <dom> ... if this is just a shortcut, then we have testability (?)
15:16:55 <dom> fluffy: no comments on this; my question was at a more general level
15:17:24 <dom> ... a broader way to solve the general problem
15:17:39 <dom> ... I have no issue with Jan-Ivar's proposal
15:18:40 <dom> fluffy: "ideal" is a little bit complicated in the general sense
15:18:51 <dom> ... if it's not deterministic, it's not useful to anyone
15:18:59 <dom> ... JIB's proposal fits that requirement
15:19:28 <dom> ... inside the deterministic behavior: say a constraint where device ratio is required to be 1
15:19:41 <dom> ... and ideal width set to 400, ideal height to 600
15:20:11 <dom> ... we need to make a choice between global optimum vs local optimum
15:20:27 <dom> ... with a global optimum, you would get e.g. 500 for this case
15:20:39 <dom> ... the other approach is to pick one property to optimize for first, e.g. width
15:20:52 <dom> ... in which case you get width and height to 500
15:21:19 <dom> ... for the use cases I can think of, local greedy algorithms seem a better match
15:21:24 <AndyH> AndyH has joined #mediacap
15:21:28 <dom> ... and J-I proposal fits there
15:21:45 <dom> ... but for them to be deterministic, we need an order
15:21:59 <dom> ... since we've renounced to let authors set that order, we should set a default order
15:22:22 <dom> ... for instance, based on the alphabetical order of their names
15:22:38 <dom> ... once we have that, we need to determine how to determine the optimal value
15:23:03 <dom> ... could be default metrics, but there are other models, e.g. squared metrics
15:23:13 <dom> ... is this making sense?
15:23:36 <dom> burn: yes; note that metrics need to be nuanced with e.g. binary values
15:24:16 <dom> fluffy: my proposal is to define some default metrics, but open the way for different metrics for different constraints
15:24:27 <lgombos_> lgombos_ has joined #mediacap
15:25:14 <dom> ... in particular, some constraints might have enumerated values where there is a logical order
15:25:22 <dom> ... (e.g. low / medium / high)
15:26:03 <dom> ... So the greedy ones are easier, the global ones more powerful, but not clear whether we need the power of global
15:26:08 <Zakim> + +30210818aaee
15:26:18 <dom> ... but given that the ideal supporters are not around, I'm a bit worried we will get a biased decision
15:26:33 <dom> ... then we need to define our metrics, and define the order on which these metrics are built
15:28:18 <Dini> Dini has joined #mediacap
15:28:37 <dom> hta: the algorithm that J-I noted, the way how you add the various constraint change from local to global
15:28:41 <fluffy> q ?
15:28:45 <dom> s/way how/way
15:28:49 <dom> s/change/changes/
15:28:51 <fluffy> q+
15:28:53 <dom> s/constraint/constraints/
15:29:44 <dom> fluffy: I think we can find ways to specific this concisely; I'm more worried about what to specify
15:29:50 <jib> q+
15:30:04 <dom> burn: I want to raise a question about how deterministic we want this algorithm to be
15:30:37 <dom> ... J-I proposal is not as deterministic as what Cullen is asking for
15:30:51 <dom> fluffy: J-I, do you mean the algorithm to be deterministic?
15:31:05 <dom> jib: no, I don't
15:31:23 <dom> ... I misled the discussion by saying "no additional features"
15:31:39 <dom> s/I misled/@@@
15:31:54 <dom> ... if we say everything is deterministic, there is no room for UA discretion
15:32:06 <dom> ... we already have "advanced" for a complete deterministic approach
15:32:20 <dom> ... "ideal" is for people that don't have that level of requirements
15:32:24 <fluffy> q?
15:32:36 <dom> ... and are happy for the UA to pick reasonable values
15:32:38 <Cow_woC> Why do we need UA discretion? The only point of the current approach (as I understand it) is to avoid fingerprinting. You don't need UA discretion for that.
15:32:44 <jib> q-
15:33:08 <dom> fluffy: if you want to say "the largest video possible", you can in theory get it with advanced, in practice, it's not practical
15:33:46 <dom> ... a deterministic algorithm doesn't imply no room for distinct behavior between UA
15:33:54 <dom> jib: I don't think I understand that
15:34:13 <dom> fluffy: I meant deterministic as the user should be clear on what to expect
15:34:23 <dom> ... the same way the "random" function is deterministic
15:35:42 <jib> q+
15:35:50 <hta> there are three things being talked about - "all browsers behave the same", "we set up common user expectations, but browsers may differ", "the spec is silent".
15:35:54 <dom> burn: my main concern is getting testability (with some range of testable)
15:36:58 <Zakim> +[Mozilla]
15:37:03 <dom> fluffy: the main point is that if the constraints ask for "ideal width" of 50, "ideal height" of 50, and the device is capable of it, the browser must give that
15:37:13 <dom> burn: I agree
15:37:17 <dom> jib: I agree too
15:37:46 <dom> ... getting "ideal" implemented with the existing algorithm makes it easier to implement
15:38:03 <ekr> ekr has joined #mediacap
15:38:20 <dom> hta: I hear rough agreement on J-I proposal, with some additional expectations on local/global
15:38:26 <dom> stefanh: also questions around metrics
15:39:07 <dom> fluffy: J-I's proposal talks about "range center" — that implies linear metrics, and doesn't work for non-numeric values
15:39:40 <dom> burn: I think to make progress on this is to provide a list of constraints with ideal, combined with scenarios of what the underlying browser is actually capable of
15:39:55 <dom> ... and see what would be reasonable outcomes and then evaluate the algorithm
15:40:15 <dom> fluffy: getting back to my earlier example…
15:40:28 <dom> hta: that example is actually a user that can't make up his mind?
15:41:03 <dom> fluffy: not necessarily, imagine a scenario where the window gets resized
15:42:03 <dom> fluffy: as hta noted, depending on how you construct the ideal stack, you get either a local or global optimum
15:42:48 <dom> jib: not sure we need that level of details given that advanced already provides that
15:43:01 <Zakim> +??P21
15:43:02 <dom> fluffy: I don't think I can get that via advanced with reasonable performances
15:43:05 <ekr> q+
15:43:30 <adam> adam has joined #mediacap
15:43:33 <dom> jib: but browsers can compete on what "ideal" means, from which we can learn
15:44:00 <dom> ... we can do that by leaving it up to the UA to determine which order they follow, which steps they'll increment in their comparisons, etc
15:44:42 <dom> ekr: "APIs should have deterministic outcomes" makes me sad
15:44:54 <Zakim> + +44.190.881.aaff
15:45:00 <dom> ... this seems a sad outcome of avoid fingerprinting
15:45:04 <ekr> dom: APIs should have deterministic outcomes.
15:45:07 <ekr> Not having htem makies me sad
15:45:34 <dom> s/ekr:/ekr: not sticking to/
15:46:05 <dom> jib: my main concern is to get done with this, ideally without too much work
15:46:46 <ekr> q+
15:47:00 <dom> hta: we should avoid surprising the users, e.g. when an outcome ends very far from one of the "ideal" constraints
15:47:12 <dom> ... the headache is to find which algorithm can be realistically developed for that
15:47:39 <dom> fluffy: your earlier proposal seemed to accomplish that
15:47:55 <dom> hta: if you make reasonable assumption on incremental steps, order of constraints, etc
15:48:00 <dom> ... that makes a lot of things to specify
15:48:03 <lgombos_> lgombos_ has joined #mediacap
15:48:33 <dom> jib: if we specify alphabetic order, and an increment step, we're good?
15:48:55 <dom> fluffy: I think so; and of course, browsers can follow a different algorithm as long as it gives the same result
15:49:49 <dom> burn: "ideal" is meant to be simple; the minimum requirement is that if the browser can provide a configuration that matches all the ideal, it should
15:50:19 <dom> ... if it can't, fluffy's algorithm seems reasonable, but there can be other reasonable approaches
15:50:53 <dom> ekr: we're talking overcomplicated algorithms only to avoid property enumeration of devices
15:51:02 <dom> ... I think we should revisit this decision instead
15:51:27 <dom> burn: it's not that simple; there is the case of multiple concurrent usage of a given device where you want the UA to have freedom
15:51:59 <dom> ... likewise for transmission on peerconnection
15:52:57 <dom> ekr: to solve concurrent requests, you could simply say "the last one to ask is has the least say in what he gets"
15:53:41 <dom> ... I think getting weird behavior from other apps using the cameras
15:53:50 <dom> ... is not acceptable
15:53:59 <dom> burn: the spec has been defined that way since day one
15:54:31 <dom> ... I think we're going into a rathole about defining a close approximation of what "ideal" gives you when it can't give you a match
15:54:40 <ShijunSun> q+
15:54:57 <jib> https://docs.google.com/presentation/d/1vtdzuPUCeIHHyW7uhIrL6TNCZZHHd0tSelX61dgw6R4/edit?usp=sharing
15:55:02 <dom> q- fluffy
15:55:03 <dom> q- job
15:55:05 <dom> q- jib
15:55:08 <dom> q- ekr
15:55:22 <dom> jib: so if we were to remove "ideal"
15:55:55 <burn> burn has joined #mediacap
15:56:11 <dom> ... we could back to the "mandatory" heading syntax
15:56:20 <dom> ... as long as we have the list of supported capabilities, I'm fine with that
15:57:04 <dom> ... this gets us back close to what we had earlier
15:57:45 <dom> ShijunSun: we like the "ideal" definition as a hint
15:57:55 <dom> ... different devices might have different capabilities and settings
15:58:15 <lgombos_> lgombos_ has joined #mediacap
15:58:20 <dom> ... depending on the scenarios (e.g. local or rtc), the UA will adapt
15:58:38 <dom> ... it's difficult to define how close the UA should target
15:58:45 <dom> ... since that depends on the devices and scenarios
15:59:00 <dom> ... "advanced" is already there for deterministic precise behavior
15:59:13 <dom> ... I think we should stick to "ideal" being simple
15:59:30 <dom> fluffy: none of the algorithms under discussion allow for adaptation under changing circumstances
16:00:07 <fluffy> q?
16:00:10 <fluffy> q+
16:00:13 <ShijunSun> q-
16:00:14 <dom> [+1 to ShijunSun FWIW]
16:00:48 <dom> fluffy: "ideal" is an optimization problem
16:01:07 <dom> ... it looks useful, but we may have to reconsider it if we can't specify it
16:01:36 <Cow_woC> An API that leads to unreliable (non-deterministic) results will not be used for anything except "Hello World".
16:01:38 <burn> I think fluffy above said that none of the algorithms under discussion prevents adaptation under changing circumstances
16:01:41 <dom> hta: we have promising discussions, but no consensus, and lack of input from the "ideal" supporters
16:01:50 <Zakim> -fjh
16:02:11 <dom> fluffy: I see a range of proposals, and can imagine their implementation impact
16:02:19 <dom> ... I don't really care about greedy or global
16:02:27 <dom> ... we need to base our decision on requirements
16:02:55 <dom> ... I care for it to be deterministic
16:03:18 <dom> ... which then gets us into ordering and metrics considerations
16:03:35 <dom> ... once we have these, I think the algorithm should be easy to build
16:03:51 <dom> ... I heard ekr say we should forget about the whole thing and fingerprinting
16:04:12 <dom> stefanh: would you be willing to write this up as a proposal?
16:04:28 <dom> fluffy: J-I, are you interested to work with me on turning your proposal into a global proposal?
16:04:31 <dom> jib: sure
16:04:51 <dom> ACTION: Cullen to work with JIB on a proposal for "ideal"
16:04:51 <trackbot> Created ACTION-29 - Work with jib on a proposal for "ideal" [on Cullen Jennings - due 2014-07-02].
16:05:13 <dom> Topic: "how long do permissions last"
16:05:54 <dom> hta: I think we have a clear picture of what people want now
16:06:24 <stefanh> Harald's slides: http://lists.w3.org/Archives/Public/public-media-capture/2014Jun/att-0137/June_Media_Capture_Bug_Walkthrough.pdf
16:06:25 <dom> ... single use permissions last until all tracks source from a given device stop
16:06:54 <ekr> This seems satisfactory to me
16:07:17 <dom> ... device names are available until all devices have stopped
16:07:35 <dom> ... stored permissions last until revoked
16:07:41 <ekr> With the caveat that obviously if we were to go to direct access, then this last bullet would be irrelevant
16:08:02 <Zakim> + +1.602.380.aagg
16:08:34 <dom> fluffy: I'm not sure how "closed" ties to what the user will perceive
16:09:40 <dom> hta: permission goes away when javascript closes the stream or user revokes it
16:10:06 <dom> ekr: the user perception question ties to the "indicator" question
16:10:32 <dom> ... we have two indicators ("can tap" and "is tapping")
16:10:49 <lgombos> lgombos has joined #mediacap
16:11:05 <dom> fluffy: I think the permission should be linked to indicators
16:11:18 <dom> ekr: they are linked by the "can be used" indicator
16:11:41 <dom> ... the question is what makes you lose the ability to use a capture device?
16:12:11 <dom> ... and that's by the user muting the mike or the app closing the stream
16:12:39 <burn> q+
16:12:44 <ShijunSun> q+
16:12:47 <fluffy> q-
16:12:48 <dom> hta: this is a matter of distinguish the cause and the effect
16:13:02 <dom> jib: re access to the labels
16:13:13 <dom> ... I sent a mail on this
16:13:18 <dom> s/jib/adambe/
16:13:47 <dom> ... there is not much point in revoking access to data once it's been granted, since it can be stored separately once it has been obtained
16:14:19 <dom> ... although we should "hide" new information until permission is granted again
16:14:31 <dom> hta: you're right, this is specifically about new devices
16:15:38 <dom> ekr: agree that there is no much sense in protecting names that were already shared
16:15:41 <ekr> oh, sorry, didn't realize we ahd a queue
16:15:44 <dom> q?
16:17:07 <dom> ShijunSun: from a security and privacy perspective, any part of the page (incl. iframes) can trigger getUserMedia and thus the permission UI
16:17:33 <dom> burn: just before the call, I've reviewed all the emails linked to permissions in the last month or so
16:17:44 <dom> ... what is the outcome on the "reload" issue?
16:17:46 <ShijunSun> q-
16:18:00 <dom> hta: since we're trying the permission to the survival of JavaScript objects, we don't survive reload
16:18:06 <dom> s/trying/tying/
16:18:23 <dom> burn: I'm happy with that, but just wanted to clarify it in the context of this decision
16:19:11 <dom> ShijunSun: just to be clear, there is distinction between "suspend" (e.g. on mobile devices) and "reload"
16:19:22 <dom> ... we should survive suspend
16:19:26 <dom> hta: yes, as other JS objects
16:19:36 <dom> burn: and that also matches my expectations as a user
16:20:32 <peter> peter has joined #mediacap
16:20:33 <dom> RESOLVED: bug 22214 resolved as per the proposal (making sure the text matches this)
16:20:48 <dom> Topic: Bug walk through
16:21:24 <dom> hta: bug 25248: stop() method and "ended" event
16:21:50 <dom> ... some APIs do as we currently do (don't signal your own actions)
16:21:57 <dom> ... but I like the consistency of always firing
16:22:14 <dom> adambe: I prefer consistency with other APIs in the platform
16:22:45 <dom> ... for stop(), it's no big deal, but for addTrack and removeTrack, it gets trickier
16:22:59 <dom> ... I think we should keep it the way it is
16:24:36 <dom> ShijunSun: I think always firing better, since it allows better layering of libraries
16:25:01 <dom> q+
16:25:40 <dom> burn: so the question is whether "ended" fires only when a stream stops outside of script control, or fires in all cases of stopping a track
16:25:46 <lgombos> lgombos has joined #mediacap
16:26:25 <dom> ... so the question is what will get done in the "ended" handler
16:26:42 <dom> ... and it seems consistent to handle all "ended" events consistently
16:27:04 <dom> ... (whereas adambe's example of addTrack might follow a different model)
16:28:18 <dom> dom: I think we should go as other APIs do
16:28:44 <dom> ... and if we hear clear dev feedback that this is bad, we can always revise it
16:29:13 <dom> ... consistent eventing of "ended" can be dealt in user land in any case
16:29:38 <ekr> If we're voting, I vote against firing
16:29:55 <dom> hta: I'm hearing more arguments for not firing than firing, and no particularly strong argument for firing
16:30:07 <dom> ... so I suggest we keep the spec as is
16:30:33 <dom> hta: will take the remaining bugs to the list
16:31:14 <dom> ... Please note the "How You Can Help" slide: in particular, clear bug reports, and pull requests to fix them
16:31:29 <dom> fluffy: for controversial topics, avoid bugzilla and pull requests, prefer the list
16:31:40 <dom> ... for clear mistakes, pull requests are perfect
16:32:14 <dom> Zakim, list attendees
16:32:14 <Zakim> As of this point the attendees have been Dan_Burnett, [Microsoft], fjh, stefanh, gmandyam, +1.267.934.aaaa, jib, dom, +46.1.07.14.aabb, +1.403.244.aacc, adambe, fluffy,
16:32:18 <Zakim> ... +47.41.44.aadd, hta?, +30210818aaee, [Mozilla], +44.190.881.aaff, +1.602.380.aagg
16:32:27 <dom> RRSAgent, draft minutes
16:32:27 <RRSAgent> I have made the request to generate http://www.w3.org/2014/06/25-mediacap-minutes.html dom
17:28:52 <lgombos> lgombos has joined #mediacap
17:52:27 <jib> jib has joined #mediacap
18:43:21 <ekr> ekr has joined #mediacap
18:52:22 <jib> jib has joined #mediacap
20:17:51 <lgombos> lgombos has joined #mediacap
20:39:02 <jib> jib has joined #mediacap
21:03:33 <jib> jib has joined #mediacap
21:33:05 <ekr> ekr has joined #mediacap
21:59:31 <jib> jib has joined #mediacap
22:21:45 <jib> jib has joined #mediacap
23:01:08 <timeless__> timeless__ has joined #mediacap
23:03:46 <slightlyoff__> slightlyoff__ has joined #mediacap
23:04:53 <Josh_Soref__> Josh_Soref__ has joined #mediacap