00:51:06 RRSAgent has joined #mediacap 00:51:06 logging to http://www.w3.org/2013/11/14-mediacap-irc 00:51:08 RRSAgent, make logs public 00:51:08 Zakim has joined #mediacap 00:51:10 Zakim, this will be MCAP 00:51:10 ok, trackbot; I see UW_MdCap()7:00PM scheduled to start 51 minutes ago 00:51:11 Meeting: Media Capture Task Force Teleconference 00:51:11 Date: 14 November 2013 00:51:20 Chair: stefanh 00:51:48 Agenda: http://www.w3.org/wiki/November_14_2013 00:51:54 silvia has joined #mediacap 00:52:19 jinkyu_seong has joined #mediacap 00:52:48 gmandyam has joined #mediacap 00:53:55 DanD has joined #mediacap 00:56:14 burn has joined #mediacap 00:56:22 kazho has joined #mediacap 00:57:01 UW_MdCap()7:00PM has now started 00:57:02 + +1.403.244.aaaa 00:57:17 fluffy has joined #mediacap 00:58:03 Zakim, call Taishan 00:58:03 ok, dom; the call is being made 00:58:05 +Taishan 00:58:25 Zakim, aaaa is fluffy 00:58:25 +fluffy; got it 00:59:07 jib_ has joined #mediacap 01:00:20 +jib 01:02:40 Zakim, who's on the call? 01:02:40 On the phone I see fluffy, Taishan, jib 01:03:51 Scribe: gmandyam 01:03:59 Topic: Minutes approval 01:04:02 DanD has joined #mediacap 01:04:02 adambe has joined #mediacap 01:04:15 minutes to approve: http://lists.w3.org/Archives/Public/public-media-capture/2013Sep/0232.html 01:04:41 Stefan: Minutes approved. 01:04:48 -> http://www.w3.org/wiki/November_14_2013 Agenda 01:05:02 Stefan: Agenda bashing ... 01:05:07 jesup has joined #mediacap 01:06:20 +jesup 01:06:24 Stefan: Will cover Image Capture and Recording towards end of meeting if time permitting 01:06:51 http://www.w3.org/wiki/images/a/a6/LC_ambition.pdf 01:06:54 http://www.w3.org/wiki/images/a/a6/LC_ambition.pdf 01:07:43 Stefan: Dec. 6 is planned for issuing CFC on Last Call. Last Call period would be from Dec. 15 to Jan. 15. 01:08:07 Dan: How does the change in process discussed at Plenary apply? 01:08:23 Dom: The new process will not be applicable to this document. It won't be ready in time. 01:08:38 yahui has joined #mediacap 01:09:27 -> https://lists.w3.org/Archives/Member/chairs/2013OctDec/0075.html Proposed revisions to the Recommendation Track process 01:09:57 Dan: FYI for remote attendees: at the Plenary yesterday a new process was discussed where Last Call is redefined so that it comes after final review. 01:10:15 -> http://www.w3.org/2013/Talks/sz-tpac2013/ (presentation given about changes to REC track process) 01:10:55 Topic: Status overview "Media Capture and Streams", what stops LC 01:11:52 Dan: I have not walked through the document to see what all needs to happen to proceed to LC. The intro of constrainable I/F has been the biggest change, but a lot of the remaining text is not aligned with constrainable. This will confuse reviewers. 01:11:56 -> https://www.w3.org/Bugs/Public/buglist.cgi?component=Media%20Capture%20and%20Streams&product=WebRTC%20Working%20Group&resolution=--- Open Bugs on Media Capture and Streams 01:12:06 stephane has joined #mediacap 01:13:04 Dan: How to obtain source settings is an item that needs to be taken up. The satisfied constraint may not be consistent with the source setting. 01:13:42 Dan: Sent out a native states proposal to the list. Seems to be consensus within the TF. 01:13:43 +Jim_Barnett 01:14:19 Adam: Have been working on resolving bugs. There was a call to create bugs. Have been going through that list and resolving. 01:14:35 Zakim, who's noisy? 01:14:46 dom, listening for 10 seconds I heard sound from the following: fluffy (11%), Jim_Barnett (10%), jesup (11%) 01:14:52 JimBarnett has joined #mediacap 01:14:57 Adam: Editors have ordered the bugs into two categories: (1) Ready for inclusion n the spec, and (2) needs more debate. 01:15:00 weird - I am muted 01:15:08 me too 01:16:51 jib_: Have concerns about constrainable. 01:17:17 Dan: Will go over constrainable, including whether Peer Identity/noaccess are in fact constraints. 01:17:28 -> https://www.w3.org/Bugs/Public/show_bug.cgi?id=22594 bug on "noaccess / peer identity as constraints" 01:17:48 Stefan: Is the schedule realistic from the editors' perspective? 01:19:00 Cullen: My suspicion is that LC will result in a large number of comments, many of which have been put forward to the list before. But I think we should still push forward for LC. 01:19:32 http://www.w3.org/wiki/images/f/fa/BurnettConstraintsTPAC2013.pdf 01:19:39 Stefan: Moving on to Constraints and Constrainable ... 01:19:52 Zakim, Taishan holds gmandyam, adambe, richt, Travis, silvia, DanD, stephane, alexandreG, dom, burn, stefanh 01:19:52 +gmandyam, adambe, richt, Travis, silvia, DanD, stephane, alexandreG, dom, burn, stefanh; got it 01:19:57 Dan: This is not intended to be a discussion as to whether constraints are useful. 01:20:08 I agree with Cullen - we will get a lot of "oh, now that I read it" comments and "I made a comment 10 months ago and no one replied" 01:20:39 Dan: It may not be appropriate to use constraints in all places (e.g. in WebRTC). This is confusing to newcomers to the specifications. 01:21:01 Travis has joined #mediacap 01:21:04 fluffy_ has joined #mediacap 01:21:06 Dan: We will have a review in WebRTC. We will have to do the same thing for Peer Identity and noaccess. 01:21:20 -> http://www.w3.org/wiki/images/f/fa/BurnettConstraintsTPAC2013.pdf Dan's slides on Constraints 01:21:38 On slide 1 01:22:13 Dan: (Slide 2) Constrainable properties represent a cross between what the UA needs/offers and what developers require. 01:22:15 On slide 2 01:23:51 Dan: (Slide 3) Web success is due to "browser default intelligence". 01:24:33 slide 3 01:24:35 Present+ Rich_Tibbett 01:24:52 Travis: Browser is flexible enough to take any input and try to make sense of it. 01:28:09 Dan: (Slide 3) Developers using gUM need to work with shared devices. For WebRTC, networks may be unpredictable resulting in negotiation failure or transport failure. 01:29:17 Dan: (Slide 3) With flexibility implementers can offer improved performance both in capture and networking. 01:29:36 q+ 01:30:12 ack jesup 01:30:36 jesup: adjusting resolution arbitrarily has impacts particularly to mobile performance. 01:30:49 jesup, please enter in IRC if I've oversimplified or gotten it wrong 01:31:53 Dan: (Slide 4) app developers need predictability/controllability for their app 01:31:54 gmandyam: Adjusting resolution automatically is especially useful if you have a mobile device, since the overhead at capturing at 10x the pixels needed wastes CPU/power and may limit frame rate 01:33:21 s/gmandyam:/jesup:/ 01:33:40 Dan: (Slide 5) Each capability in the constraint approach has a range of acceptable values, whether an error event must be raised if the contraint cannot be met ("Mandatory"), and ordering of optional constraints based on priority. 01:35:05 q+ 01:35:11 q+ richt 01:35:39 ack gmandyam 01:36:26 q+ 01:36:32 wonsuk has joined #mediacap 01:36:45 gmandyam: if the mandatory constraint is set to 419x299, should be the browser throw an error event if it can only do 420x300? 01:37:26 burn: yes; a developer can use min/max values instead, but if the dev requests a mandatory value with that specificity, he'll get what he's asking 01:37:45 gmandyam: that confirms my understanding; this will require a lot of developers education 01:37:51 q+ 01:38:00 ack richt 01:38:22 richt: Mandatory constraints are not best effort. It is all or nothing. There is no fallback. 01:38:54 richt: The idea that it is better to fail is an exclusionary model. 01:39:16 q+ fluffy 01:39:18 q+ 01:39:18 richt: This is a "first world" type of approach. 01:39:29 ack jib 01:40:05 Q+ 01:40:20 jib: you qualified what developers get from an unmet constraint as failure; but that's not exactly how this works with mandatory constraints 01:40:26 ... what you get is an error event later on 01:40:39 jib_: Want to clarify that "failing" upon inability to meet mandatory constraints is not really "failing." How do we deal with unknown mandatory constraints? 01:41:13 burn: We should discuss unknown mandatory after we finish the constrainable discusion. 01:41:17 No, not quite, if applyConstraints fails, you get the error callback 01:41:30 And the old constraints stay in effect 01:41:36 q- 01:41:44 q- 01:41:55 adam: Do unknown mandatory constraints result in an error or an event? 01:42:31 burn: If the mandatory constraint cannot be met upon invocation on gUM, it is an error. At a later time, it would be the overconstrained event. 01:42:40 Travis has left #mediacap 01:42:54 Travis has joined #mediacap 01:43:08 Zakim, close the queue 01:43:08 ok, dom, the speaker queue is closed 01:43:22 fluffy: "First world" is inflammatory language. Lots of people raised good use cases for this. 01:43:47 q- 01:43:57 ack JimBarnett 01:44:11 q- 01:44:36 Zakim, reopen the queue 01:44:36 ok, dom, the speaker queue is open 01:44:38 JimBarnett: If there is a failure to apply a constraint, then no changes occur to the existing device state. 01:44:50 [slide 6: sample Use Cases] 01:45:08 burn: (Slide 6) Sample use cases - broadcasting US Presidential address, door security camera 01:47:02 (the presidential broadcast seems a stretch as a use case: here the user and the application developer are presumably tightly coupled) 01:49:38 burn: (Slide 7) Use constraints when browser does not have direct or exclusive control over capability. Use direct configuration when browser has direct and exclusive control over the capability. An example of direct config. would be in WebRTC: offerToReceiveAudio/Video. 01:49:52 fluffy, my point was not to be inflammatory but to highlight that it is easy to overly constrained media capture when you're sitting on a T1 connection with the latest hardware and software at your disposal. i.e. developers are not necessarily the best judges of what their users are capable of. But point taken. 01:50:02 q+ 01:50:29 Travis: Is a direct config. the same as defining an API method to invoke? 01:50:42 burn: A direct config. is a normal setting. 01:51:00 q+ 01:51:11 Dom: Direct config. is the same as non-constrained approach. 01:52:40 burn: Browser in WebRTC use cases may need to take action more quickly than would be allowed with API control (e.g. congestion control). 01:53:13 Dom: Peer Identity and noaccess are not constraints, based on this definition. 01:53:18 ack jesup 01:54:10 jesup: It would be useful for people to come up with media capture examples as opposed to WebRTC examples. For example, noise suppression is something you just turn on and don't think about. 01:54:28 ywu has joined #mediacap 01:54:38 ack me 01:54:49 q+ 01:55:05 burn: Noise suppression would probably be a setting if it is simply an on/off feature. But different levels of noise suppression could lend itself to constraints. 01:55:34 q+ 01:55:48 ack adambe 01:55:52 q- 01:56:17 lgombos has joined #mediacap 01:57:00 adambe: Constraints should include capabilities, range constraints, and settings (direct config). 01:57:28 burn: I think this is heading into the mandatory unknown constraints discussion, which we will take up later. 01:58:10 brun: (Slide 8) types of constraints include property value range, and enumerated list (e.g. of source ID's or booleans) 01:58:20 brun - > burn 01:58:38 s/brun:/burn:/ 01:58:58 Q+ 01:59:12 +q 01:59:24 burn: (Slide 9) Describes difference between capabilities, constraints, settings 01:59:28 +q 01:59:31 q+ 02:00:20 q+ 02:00:27 Travis: Going back to door security camera example. Given that we have capabilities, we have no ability to express a preference without constraining. 02:00:44 burn: The way to specify preferences is by an ordering of optional constraints. 02:01:21 Travis: We should put an example in the spec. It is a good feature. 02:01:47 ack Travis 02:02:05 ack DanD 02:03:28 DanD: Constraints specify a distinction between "needs" and "wants", and "buy" i.e. you get what you pay for. 02:03:40 ack silvia 02:04:21 silvia: I assume the idea of this presentation was to explain constrainable. I would like to see code examples. 02:04:35 burn: I didn't want to go over syntax in this presentation. 02:05:19 burn: This mechanism was present before the constrainable interface was spec'ed. 02:05:26 q? 02:06:15 ack gmandyam 02:06:47 gmandyam: imagine I have a physical device that the end-user can directly control 02:07:10 ... the app developer uses the constraints mechanism to adjust a setting the user can control physically 02:07:29 ... once the dev gets the stream, the user fiddle with that setting 02:07:48 ... the app dev will then get an overconstrained event 02:07:51 q+ 02:08:13 mreavy has joined #mediacap 02:08:15 Travis: this means you have to threaten the user? :) 02:08:21 Burn: you can't stop the user from doing that 02:08:30 ... no matter what mechanism you use 02:10:01 anssik has joined #mediacap 02:10:08 Present+ Anssi_Kostiainen 02:10:13 dom: mandatory constraints requires tight coupling with the end-user 02:10:23 q? 02:10:29 ... as the US presidential broadcast (stretchedly) illustrates 02:10:39 ... we should make it clear to developers 02:10:42 ack me 02:10:48 q+ 02:10:48 ack jesup 02:13:46 there's no reason that you can't specify an enumerated set of values for a range 02:14:10 jseup: One of type of request seems hard to specify. You need a set of values that are a subset of a range and are known (e.g. QCIF, or codecs w/fixed resolution sizes). It is going to be hard to specify. fps would not be suitable for a range, but more to a set of acceptable values. Optional does not really allow this. 02:14:40 burn: We could move beyond min/max and enumerable types of contraints to handle this. 02:14:50 ack jesup 02:16:13 ack anssik 02:17:27 anssik: We have one real-world use case: exposing getStream over gUM (e.g. for multiple cameras). I would like to see how we can facilitate extensions in the future. We want the base functionality to be shipped ASAP. 02:17:34 q? 02:17:47 s/getStream/depth stream/ 02:18:22 adambe: Are you going to discuss the list of constraints that are mandatory to be supported. 02:18:25 q+ 02:19:36 adambe: The mandatory vs. optional is really the tough debate. We should just focus on the list of constraints. There is consensus on use of constraints. 02:20:21 ack fluffy 02:20:23 q+ 02:21:14 q+ to say one way would make it to make mandatory constraints *harder* to request 02:21:15 fluffy: We should sort out future mandatory constraints. I think the implementation should fail any unknown mandatory constraints. Our advice to developers would be not to use mandatory constraints if you don't know what you are doing. 02:22:00 q+ 02:22:37 jib_: Dictionaries are by definition designed to ignore unknown keys. 02:22:38 ack fluffy 02:23:45 cullen: WebIDL doesn't bother me. Let's say in the future we extend to 3D cameras. Assume you request as mandatory a 3D camera when the browser doesn't support the constraint. You want it to fail. 02:24:27 jib_: There is another way. The browser provides a method that gives information on what it actually supports. 02:24:53 \jib_: You should not use mandatory as a developer unless you have a fall back. 02:24:58 q? 02:25:21 q+ 02:25:43 jib_: This not good for novice developers. 02:26:00 well, seems that I completely agree with jib_ 02:26:32 q+ 02:26:38 dom: Most of the tension is on mandatory vs. optional. Future mandatory is not a separable issue. 02:26:54 lgombos has joined #mediacap 02:27:22 dom: Maybe the natural way is to make it harder to request a mandatory constraints. 02:27:34 +1 on default thing is an optional constraint and need to do something extra to be mandatory 02:27:36 I can see that working dom. 02:27:53 burn: I don't mind making it more "difficult" to request a mandatory constraints. 02:27:57 ...pending a proposal 02:28:10 q? 02:28:15 q+ 02:28:20 I'll try to think of the appropriate syntax to make mandatory constraints harder 02:28:31 +1 on optional being the default, mandatory needs extra work/parameters/etc 02:28:31 ack me 02:28:31 dom, you wanted to say one way would make it to make mandatory constraints *harder* to request 02:28:39 ack adambe 02:28:42 Travis: Mandatory and optional should not be at the same level of "easiness". 02:29:29 adambe: I like this direction. We should pursue a default of optional, and something extra must be done to achieve mandatory. 02:29:53 Chairs: We need to see proposals. 02:30:09 One thing to do would be to require a constructor for mandatory constraints 02:30:36 ack burn 02:30:39 q? 02:30:47 ack silvia 02:30:50 richt: This is a good direction. Default use of mandatory could mean that there is a good chance your app is unusable, which is not the way of the web. 02:31:43 silvia: I like the mandatory part. I don't think optional is sufficient. The browser will be conservative when specifying a range of values. 02:31:53 q+ 02:32:39 ack jib_ 02:33:30 -jib 02:33:53 ack JimBarnett 02:33:54 q? 02:34:14 JimBarnett: 3rd paragraphs of Ch. 10 provides an example for Silvia. 02:34:36 ywu has joined #mediacap 02:34:38 q+ 02:34:44 +jib 02:34:48 q+ 02:35:18 Zakim, close the queue 02:35:18 ok, dom, the speaker queue is closed 02:35:32 q? 02:35:51 silvia: A special value denoted as "best" would be better than an ordered list. 02:36:12 ack jib_ 02:36:49 I don't think width:1920, width:1280, width:1024, ..... is a great way to say "max" :-) 02:37:36 jib_: Mandatory constraints should be WebIDL dictionaries. The current spec is not consistent with the WebIDL specification. 02:38:04 q+ 02:38:12 -Taishan 02:38:19 q- 02:38:33 I should note jib has been wrestling on how to implement constraints within the browser and make it interface to the DOM and WedIDL code 02:38:52 Zakim, call taishan 02:38:52 ok, dom; the call is being made 02:38:54 +Taishan 02:38:57 Silvia brings up a good point--that Chrome currently is not giving "best effort" as the default, but rather 640x480. 02:39:17 That's why she want to set "best effort" as a preference. 02:39:29 travis, silvia, yes, so the interesting question is why 02:39:44 I think the spec should make "best effort" the default--so that it will be clear that Chrome has a bug. 02:40:15 jib_: The implementation needs to provide a method as to what mandatory constraints it supports. 02:40:16 audio is good now 02:40:21 ack fluffy 02:40:42 q+ 02:41:17 fluffy: Re: getting the max video resolution. We agreed that absent constraints, the browser would provide max resolution and fps as default. We should provide advice as to what the browser should do with no presented constraints. 02:41:42 Silvia: Implementations like Chrome don't do that today. By default, we may not want post highest res video on the internet. 02:41:52 cullen: what if max frame rate is at 640:400 @ 120fps, and max resolution is at 1920:1080 (@5fps) 02:42:08 dom: There is a question as to what to optimize first, absent provided constraints. 02:42:25 what type of phone are you using on shenzen? is it a voip connection? 02:42:26 can't optimize both, so the behaviour is poorly specified - which may be ok, but we should be clear 02:42:42 We are going on break in Shenzhen until 11:10 local time 02:42:43 -Taishan 02:42:44 -jib 02:42:45 lgombos_ has joined #mediacap 02:42:52 also, if there is agreement that lacking constraints the browsers should provide the best, then that needs to be in the spec 02:42:59 -jesup 02:45:58 frame rate preference (up to max X fps) versus quality(resolution) preference (down to min X fps) is common for apps to want. And not it's not just an optional "frame_rate: best"; the camera might do 240fps and you may not want more than 60. 02:46:22 configuration/preferences for this sort of stuff has enough edges cases to fill a dozen ratholes ;-) 02:55:01 mreavy_ has joined #mediacap 03:10:36 dom has joined #mediacap 03:10:46 dom_proj has joined #mediacap 03:11:06 +jib 03:11:16 Zakim, call taishan 03:11:16 ok, dom; the call is being made 03:11:17 +Taishan 03:11:52 Zakim, who's on the call? 03:11:52 On the phone I see fluffy, Taishan, Jim_Barnett, jib 03:11:53 Taishan has gmandyam, adambe, richt, Travis, silvia, DanD, stephane, alexandreG, dom, burn, stefanh 03:12:27 -Taishan 03:12:54 Zakim, call taishan 03:12:54 ok, dom; the call is being made 03:12:55 +Taishan 03:15:04 ScribeNick: dom 03:15:56 burn: summarizing from before the break 03:16:11 ... there is agreement that the constraint approach is workable 03:16:19 stefanh has joined #mediacap 03:16:42 ... one suggested modification (lacking concrete proposal yet) has been to make it less obvious/less easy to request mandatory constraints (vs optional ones) 03:17:16 ... another suggestion has been to indicate they want some extreme value of an actual property (e.g. max width without knowing what that actual value is) 03:17:37 ... both of which are doable, hopefully not requiring a horrendous effort 03:17:46 +jesup 03:17:49 q+ 03:17:50 ... still some uncertainty about how to deal with mandatory constraints for unknown properties 03:17:54 Zakim, reopen the queue 03:17:54 ok, dom, the speaker queue is open 03:18:00 q+ 03:18:02 stefanh: that matches what I heard 03:18:16 adambe: in the spec we have a limited amount of space for constraints 03:18:34 ... would it be useful to list examples and how they're met with use cases 03:18:37 ... e.g. an appendix 03:18:53 ... this would also help ensure we can achieve these use cases 03:18:57 burn: sounds good 03:18:59 DanD has joined #mediacap 03:19:20 gmandyam: I've assumed that constraints defined in the spec are mandatory to be implemented 03:19:57 gang has joined #mediacap 03:20:20 ... is that everyone's understanding? 03:20:21 q+ 03:20:24 burn: yes 03:20:26 q+ 03:20:29 q+ 03:20:31 ack gmandyam 03:20:35 q+ 03:20:36 dom: we will have test cases to verify that 03:20:41 ack jesup 03:20:59 burn has joined #mediacap 03:21:01 jesup: what does support mean in this case? is it "recognizing"? does it need to do something with it 03:21:05 burn: do as define 03:21:11 s/define/defined/ 03:21:14 q- 03:21:17 kazho has joined #mediacap 03:21:21 q+ 03:22:50 q+ 03:22:59 q+ 03:23:14 jesup: ok; that might be hard to test 03:23:35 q+ 03:24:26 dom: I share this concern; I think we can do a reasonable job to it, but we need to understand that adding something in the registry for constraints name should come with real implementation experience and testing 03:25:07 burn: the spec currently does 2 things: it defines a set of constrainable properties and requires implementation of those 03:25:24 q? 03:25:34 ... we haven't made a decision about what the conformance requirement for properties in the registry 03:26:10 burn: we should discuss registry and impact on conformance to an upcoming meeting 03:26:13 q- 03:26:20 q- 03:26:29 jungkees has joined #mediacap 03:27:34 fluffy: this is clearly something we need to discuss before we can imagine moving to Last Call 03:27:40 stefanh: we'll put it on today's agenda then 03:27:58 q+ 03:28:36 q- 03:28:37 fluffy: dealing with unknown constraint properties is also something we need to tackle at the same time 03:29:00 JimBarnett: constraints are supposed to deal with the fact with varying capabilities 03:29:13 ... which makes it hard to pinpoint what "support" means 03:29:24 ... e.g. for a property that a given camera supports 03:29:30 ack JimBarnett 03:29:32 q+ 03:29:48 Zakim, close the queue 03:29:48 ok, dom, the speaker queue is closed 03:30:03 burn: based on discussions at the break, we also need to look at permissions again 03:30:10 ... I think we're slowing converging toward an understanding 03:30:16 stephane has joined #mediacap 03:30:16 ... but we're not completely there 03:30:26 q+ 03:30:34 ... what is available before having permissions (and permission for what) 03:30:39 ... we need to have that review done 03:30:57 silvia: I want to add to the summary about the "best effort" outcome 03:31:12 ... with the possibility for a constraint to give the best possible value 03:32:03 ... I would suggest having special values e.g. "maxPossible" 03:32:04 ack 03:32:09 ack jib_ 03:32:15 ack silvia 03:32:16 ack me 03:32:22 ack burn 03:32:44 jib: +1 to permissions review 03:33:02 ... esp in light of gathering info for setting mandatory constraints 03:33:13 ack fluffy 03:33:16 s/for/for or by/ 03:34:05 fluffy: I would like to clarify whether a browser without a given hardware can be conformant to gUM 03:34:11 dom: the algorithm already ensures this 03:34:13 I 03:34:47 I'd like to see getUserMedia available on browsers/machines with *no* cameras or mics :-) 03:35:36 Topic: Constrainable 03:36:15 JimBarnett: Constrainable will have to change a lot in light of our discussions 03:36:33 ... so probably not worth doing this now 03:36:46 Topic: Lifecycle 03:37:07 -> http://www.w3.org/wiki/File:Life_cycle_session.pdf Adambe's slides on lifecycle 03:37:44 adambe: [slide 2: mediastream state - recent changes] 03:37:57 ... ended has been replaced with inactive as we moved everything to tracks 03:38:22 ... mediastream is just a container whose state is a convenience shortcut to the collective state of the tracks 03:38:50 ... reflecting whether any contained track is active 03:39:07 ... should we switched to a positive (active) state instead of the current "inactive" one? 03:39:32 silvia1 has joined #mediacap 03:39:48 ACTION: adambe to switch MediaStream.inactive to MediaStream.active 03:39:48 Created ACTION-25 - Switch mediastream.inactive to mediastream.active [on Adam Bergkvist - due 2013-11-21]. 03:39:56 adambe: [slide Stopping sources] 03:40:23 ... in which context does this stopping/granting happens 03:40:37 ... when you stop a source, that said source could be used e.g. in several tabs 03:40:45 ... what should happen when you switch it off in a single tab? 03:41:02 ... the scope of stopping a source should be in the specific context in which it was created 03:41:20 ... once you've been given access to a source, you can get as many tracks as you want 03:41:23 q+ 03:41:34 ... this is the context in which you can stop a given source 03:41:36 Zakim, reopen the queue 03:41:36 ok, dom, the speaker queue is open 03:41:38 q+ JimBarnett 03:41:58 ... stopping a source in a tab doesn't stop it another 03:42:05 Giri: so this isn't linked to origin, but to tabs 03:42:34 dom: this is what is defined in HTML5 as the browsing context 03:43:03 adambe: we should explicitly say so that people don't have to think about this 03:43:22 JimBarnett: what happens when you have a track and lose permission to the source (or the track hasn't been attached yet) 03:43:35 ... what should getCapabilities() return in that case? 03:43:59 adambe: good point; but we'll need to look at this separately as part of the permission discussions 03:43:59 q- 03:44:09 adambe: [slide MediaStreamTrack.stop()] 03:44:20 ... revoking access to a source is done via the track the source is connected to 03:44:34 ... if you call the stop() method on the track, it will stop the source of the track 03:44:37 ... and it will end all the connected tracks 03:44:47 q+ 03:44:47 ... it's been requested to make it friendlier to other tracks 03:45:01 ... my counting the number of references of a given source across tracks 03:45:58 adambe: if another track is created (e.g. via cloning, or a constructor, or a new call to gUM) 03:46:08 ... every track instance would add to the reference counter 03:46:23 ... and it would be decreased on garbage collection or collecting stop() 03:46:47 silvia: what's the point of sourceId in that case? 03:47:11 adambe: it's a way to remember and recall a previously selected camera 03:48:01 travis: it's a persistent session identifier 03:48:19 q+ 03:48:34 ... if you stop a track and the source that is referenced from another track 03:48:51 ... does the MediaStream gets active=false? 03:48:56 adambe: yes (cf slide 2) 03:49:30 ... [slide MediaStreamTrack.stop() #5] 03:49:48 ... intention of the stop method is to make it possible to develop well behaving application 03:49:49 ywu has joined #mediacap 03:50:06 ... letting them to revoke no longer needed permission) 03:50:26 ... the application itself could be dealing with it on its own 03:50:35 ... but not in all cases (e.g. if you're using an external library) 03:50:49 ... so the current stop() is not nice, ref counting would be much better 03:50:57 ACTION: adambe to write ref-counting mediastreamtrack.stop() 03:50:58 Created ACTION-26 - Write ref-counting mediastreamtrack.stop() [on Adam Bergkvist - due 2013-11-21]. 03:51:13 q? 03:51:19 jesup: I generally agree with the functionality if that's indeed we intended 03:51:27 ... I don't know if ref-counting really comes into it 03:51:47 ... if you simply rewrite it as stop() applies to Track only 03:52:13 ... this will do the same and be less confusing to refer to ref counting (which only applies to dev visible objects) 03:52:21 adambe: makes sense 03:52:23 ack 03:52:29 ... [slide 6 "Proposal"] 03:52:37 ack jesup 03:52:37 ack jesup 03:52:54 q+ 03:52:54 ... if we really need an explicit stop on sources, we could add a method to MediaDeviceInfo 03:53:15 I see no need for it 03:53:15 q+ 03:53:22 ... we don't have a clear need for this (and MediaDeviceInfo can't take a methods) 03:53:34 Zakim, close the queue 03:53:34 ok, dom, the speaker queue is closed 03:53:45 q? 03:54:11 gmandyam: what stopping a source implies? turn the camera on/off? 03:54:48 adambe: this is not defined given that we don't know we need it 03:54:52 silvia: agree 03:54:57 ack me 03:55:15 lets not have side effects from one tab on other tabs in our browser 03:55:31 -jib 03:55:32 -Jim_Barnett 03:55:43 -jesup 03:55:45 -Taishan 04:09:43 lgombos__ has joined #mediacap 05:28:48 stefanh has joined #mediacap 05:29:32 dom has joined #mediacap 05:30:00 +Jim_Barnett 05:30:00 dom_proj has joined #mediacap 05:30:01 -Jim_Barnett 05:30:01 +Jim_Barnett 05:30:10 Zakim, call taishan 05:30:10 ok, dom; the call is being made 05:30:11 +Taishan 05:30:42 gmandyam has joined #mediacap 05:30:42 silvia has joined #mediacap 05:30:51 Zakim, who's on the call? 05:30:51 On the phone I see fluffy, Taishan, Jim_Barnett 05:30:52 Taishan has gmandyam, adambe, richt, Travis, silvia, DanD, stephane, alexandreG, dom, burn, stefanh 05:30:56 -Taishan 05:31:02 Zakim, call taishan 05:31:02 ok, dom; the call is being made 05:31:04 +Taishan 05:31:04 +jib 05:31:47 -Taishan 05:31:57 burn has joined #mediacap 05:32:05 Zakim, call taishan 05:32:05 ok, dom; the call is being made 05:32:06 +Taishan 05:32:30 stefanh has joined #mediacap 05:32:49 we are only hearing the rare word 05:33:29 I think it might be getting better but it is bad bad bad 05:33:36 +jesup 05:34:01 yeah! 05:34:34 ScribeNick richt 05:34:52 05:35:27 Topic: Unknown mandatory constraints 05:35:45 fluffy: If the browser comes across a mandatory constraint it doesn't recognize what should happen? 05:36:11 burn: With permissions let's discuss what information is available in the permissions check process. 05:36:38 adambe has joined #mediacap 05:36:46 jlb_: I believe strongly mandatory constraints should be WebIDL dictionaries. 05:36:49 q+ 05:36:56 Zakim, reopen the queue 05:36:56 ok, dom, the speaker queue is open 05:37:00 q+ adambe 05:37:03 jlb_: Which means anything not understood by the browser can be ignored. 05:37:12 q- gmandyam 05:37:20 jlb_: Anything the app doesn't know about it can use getCapabilities to discover. 05:37:22 s/jlb/jib/g 05:37:41 fluffy: Why should it return an error to things it does understand but not to things it doesn't understand 05:37:56 jib_: Conflating two things... 05:38:07 this is related to the registry -- we can't put all possible registered constraints into WebIDL in the gUM spec 05:38:27 burn, you could argue that the registry should be the WebIDL in the spec 05:39:20 fluffy: We're discussing things that have been agreed for a long time in this working group. 05:39:22 q? 05:39:36 jib_: A lot of people want to be able to say: 'Please give me the fake camera' 05:39:47 s/fake/face/ 05:40:12 fluffy: If they want to see all the cameras then they won't put those contraints in. 05:40:24 fluffy: You're taking the position the app cannot control the experience. 05:40:55 jinkyu has joined #mediacap 05:40:57 ack adambe 05:41:43 adambe: When we said there should be the concept of mandatory and optional but we were discussing before lunch that perhaps it's the apps job to monitor constraints. 05:41:55 adambe: You mark some and force mandatory behavior on those. 05:42:05 burn: Don't want to get in to a full proposal now but... 05:42:18 Travis has joined #mediacap 05:42:42 burn: You have a preferences list, essentially. You put your constraints in priority order but then there's a separate call. I want things in this particular way but if that can't happen then fallback to something. 05:43:08 adambe: We discussed that when you declare mandatory constriants there too easy to declare. 05:43:25 adambe: And we discussed making it harder to declare mandatory constriants. 05:43:41 fluffy: You have wants and needs. This affects what you expose in the user dialog box. 05:44:09 fluffy: The 'wants' are things that displayed that meet that. The 'needs' you want an error if you can't fulfill them. 05:44:28 dom: Even when there were mandatory constriants there was feedback from implementors that it was difficult. 05:44:43 fluffy: What are our requirements? We need to meet those use cases. 05:45:29 dom: I don't know that the use case says anything how web app developers enforce this. 05:45:56 s/I want things in this particular way but if that can't happen then fallback to something./The separate call would allow the developer to indicate a mandatory constraint with a callback if the constraint can't be satisfied/ 05:46:06 dom: The question that emerges is: What kind of discussion can we have in the absence of a proposal for mandatory constrinats discussed this morning? 05:46:23 q+ 05:46:39 fluffy: I understand that. But what we're discussing is what the basic requirements are. 05:46:45 stephane has joined #mediacap 05:46:49 fluffy: Are we hitting the reset button on this? 05:46:56 jib_: I don't think we are proposing that. 05:47:05 fluffy: Would like clarification from the chairs. 05:47:18 stefanh: When Dan presented this morning people liked it a lot. 05:47:28 stefanh: One complaint was that it was too easy to use mandatory constraints. 05:47:34 stefanh: We can design around that. 05:48:09 jib_: We make it harder for the advanced user but easier for the simple user to get along with this. 05:48:40 jib_: First you have to figure out what the browser supports. Best way to do that is to ask the browser what it has. 05:48:53 jib_: e.g. do you have 3d camera capability? 05:49:03 q+ 05:49:25 fluffy: I have a call that let's me do that. I understand that. 05:49:54 fluffy: What you're describing if I ask for the front facing camera then I want it to display the front-facing camera or nothing. 05:50:06 fluffy: You're saying your implementation won't do that. 05:50:14 jib_: That's not what I'm saying at all. 05:50:58 burn: We're talking about unknown constraints so let's discuss that. 05:51:13 fluffy: If I put in mandatory and there's no front facing camera what happens. 05:51:32 fluffy: But you're saying you will present to the user all the cameras in that case. 05:52:00 jib_: What we found was users tend to disagree with what apps want. 05:52:20 jib_: The implementation will go through the array and try to match the constraints. 05:52:21 q? 05:52:36 jib_: It penalizes someone that has more than one camera. 05:52:56 jib_: If an app asks for the back camera it will work on person A's device. 05:53:09 jib_: But won't work on person B's device. 05:53:22 jib_: My opinion is that the user should be able to override that choise. 05:53:27 s/choise/choice/ 05:53:42 And in this case, the app *said* it was optional, but the result was to effectively make it mandatory because the user can't select anything that doesn't match it 05:53:58 s/But won't work on person B's device./But won't work on person B's device if they don't have a back camera./ 05:54:16 fluffy: Suggest you write that up and send it as a proposal to the working group. 05:54:25 Can someone summarize? 05:55:02 jib_: The way to think about mandatory is like a flamethrower. 05:55:14 jib_: For the novice user getting an error is not good. 05:55:34 fluffy: I have no problem making it inconvenient to use mandatory. 05:55:45 fluffy: But we still need to make it possible to use for the advanced user. 05:56:01 q+ 05:56:01 jib_: We have a new constraint that's not mandatory to implement then you should check with the browser that it supports it. 05:56:01 q? 05:56:06 q? 05:56:08 ack burn 05:56:09 q+ 05:56:13 q- 05:56:39 burn: One of the things you've said jib_: The apps needs to check what's available re: constraints. 05:56:57 burn: We actually need our permissions discussion. What information is available before you access the device and what is available after? 05:57:18 burn: Let's say you want the front facing camera. If the browser cannot ensure I get that camera I may not want to show it. 05:57:23 burn: maybe gray it out. 05:57:35 burn: So we need to have the permissions discussion because it's related. 05:57:54 dom: That's not something you can determine for e.g. standalone webcams. 05:58:25 dom: What application will not even try to fulfill the use case in the absence of e.g. a front-facing mandatory camera request? 05:59:11 dom: It's not just that mandatory constraints change the UI but also change how much the browser can determine about the camera devices. 05:59:48 s/how much the browser/depending on whether the browser/ 05:59:57 burn: In order to answer this question we need to discuss permissions and extensibility via the registry. 06:00:09 jib_: Confused what permissions has to do with mandatory constraints. 06:00:23 dom: I agree with that. 06:00:29 fluffy: I agree with that. 06:01:08 jib_: Should be a convenient enough that when novice users use mandatory constraints there is a reasonable fallback available. 06:01:12 q+ 06:01:19 q? 06:01:21 q+ to comment on WebIDL 06:01:29 burn: In response to that, I'm not convinced on the 'this is how the web works' argument. 06:01:45 burn: Might be interesting to add ability to determine what constraints a browser might know about. 06:01:51 burn: Sounds like the registry discussion. 06:02:32 q+ 06:02:40 burn: Add capability to find out what capabilities are available. 06:02:56 DanD has joined #mediacap 06:03:00 jib_: My proposal includes making it hard to use mandatory but also to prevent mandatory to fail. 06:03:23 fluffy: Not understanding the advantage of this. 06:03:43 fluffy: q discipline please 06:03:51 dom: I thnk this discussion is not useful without a concrete proposal for handling mandatory constraints. 06:04:00 dom: Let's not base this on any assumptions we may have here. 06:04:01 q? 06:04:11 dom: Depends on what approach we eventually take. 06:04:15 sorry jesup, thought I was at front of q 06:04:34 dom: So no assumptions should be made about what the mandatory constraints proposal will look like. 06:05:06 dom: We can handle extensibility by allowing the developer to know in advance what will be recognized by the browser. 06:05:22 dom: That we're at odds with WebIDL is not a good sign. 06:05:42 dom: But WebIDL is also a moving target with new approaches all the time. 06:05:42 q? 06:05:52 dom: WebIDL is not the bible of Web API design just yet. 06:05:55 ack me 06:05:55 dom, you wanted to comment on WebIDL 06:06:00 q+ 06:06:07 ack jesup 06:06:31 +1 to jesup 06:06:34 jesup: Clear from the front/back camera discussion. Clear that there may be some constraints for which mandatory is never a good choice. 06:06:48 jesup: Need to consider whether _all_ constraints can be made mandatory. 06:06:49 [I'd claim that "camera direction" is never a good mandatory constraint to use] 06:07:27 jesup: Heard fluffy say he's ok with the idea of making mandatory constraints harder to use. 06:07:31 [and as such, should not be usable as a mandatory constraint] 06:07:37 jesup: So we define a well-understood way to do that. 06:07:57 jesup: In a way that doesn't confuse people. 06:08:32 [Travis suggests requiring using the control key to get mandatory constraints :) ] 06:08:43 jib_: That's exactly what I'm proposing. 06:08:56 fluffy: Chairs should set a date when we need requirements by on the list. 06:09:13 ack fluffy 06:09:16 fluffy: Schedule some time for people to make proposals and for others to talk through those. 06:09:42 fluffy: Worried when we look at ways of doing that it may be dubious. 06:09:52 fluffy: So let's open it up but let's schedule that. 06:09:53 ack silvia 06:09:57 q 06:10:14 silvia: Want to point out a someone having used constraints in an app with 3 cameras... 06:10:18 -fluffy 06:10:25 silvia: well aware what mandatory means in that case. 06:10:29 hmm - got disconnected 06:10:32 will dial back in 06:10:33 silvia: but it's also important to be able to catch that problem. 06:10:48 silvia: making it hard for web developers to use it is not really a goal for me. 06:10:51 I'll just say that I don't think we disagree on requirements, just on how to provide the result 06:10:55 silvia: I will find out how to use it anyway. 06:11:00 q? 06:11:04 ack jib 06:11:08 silvia: But most important is being able to catch errors and handle them. 06:11:50 jib_: I have a 3d camera. The app tells me 'I need to buy a 3d camera'. So I buy one. But it turns out the browser simply didn't recognize that. 06:12:02 +fluffy 06:12:05 silvia: I think we're discussing on different levels. 06:12:21 q/ 06:12:24 q? 06:12:25 q+ 06:12:35 silvia: We need a proposal here. 06:12:56 She's saying the error from failing mandatory should say "browser doesn't support 3d" 06:13:02 silvia: When we get an error on mandatory constraints failing we need to know why it failed. 06:13:05 kazho has joined #mediacap 06:13:08 ack me 06:13:14 Zakim, close the queue 06:13:14 ok, dom, the speaker queue is closed 06:13:16 ack burn 06:13:25 burn: Hear what you're saying jib_ . 06:13:39 burn: Need to know if the constraint itself is known and supported by the browser. 06:13:49 [feature detection, as Travis mentioned] 06:13:58 burn: Can should be able to check which constraints are supported. 06:14:11 burn: what silvia said was there are different ways we can do that. 06:14:26 burn: check prior to call or handle as an error after invocation. 06:14:28 [a good summary of this discussion would include the list of requirements we have already identified today] 06:14:32 q+ 06:14:38 burn: would be interested in seeing proposals in both of those directions. 06:14:42 ack jib 06:15:33 dom: This discussion has already identified requirements that any proposal in this space should have. 06:15:46 dom: Would be useful to conclude this 1st phase of this discussion. 06:15:58 dom: Are we aligned on the requirements we have identified today. 06:15:58 q+ 06:16:16 dom: Mandatory constraints should be less easy of less obvious than using optional constraints. 06:16:27 dom: Not all constraints should be useable in mandatory mode. 06:16:40 Gang has joined #mediacap 06:16:47 dom: Useful if developers can detect whether a given mandatory constraint is understood by the browser. 06:16:49 Dom, can I get on the queue? 06:17:11 dom: Whenever a mandatory constraint cannot be fulfilled there needs to be sufficient information back the developer so they can adapt their code. 06:18:07 ACTION: stefanh to send a call for requirements on mandatory constraints 06:18:07 Created ACTION-27 - Send a call for requirements on mandatory constraints [on Stefan Håkansson - due 2013-11-21]. 06:18:41 dom: I know some people already have ideas and requirements here. We should start writing down their ideas. 06:19:04 dom: Don't want to block on constraints for e.g. 6 more months. 06:19:21 dom: Let's write down requirements and share with the list. 06:19:30 stefanh: What's areasonable timeframe? 06:19:39 stefanh: ok. 2 weeks. 06:19:47 s/areasonable/a reasonable/ 06:20:02 adambe: no requirement on knowing when an optional constraint fails? 06:20:10 dom: There was no discussion on that. No. 06:20:31 q+ 06:20:40 kazho has joined #mediacap 06:20:47 dom: Mandatory constraints have been a hot topic for a while. 06:20:58 dom: There wasn't much clarity how and when those constraints should be used. 06:21:09 dom: So this is an effort to clarify those points. 06:21:26 stefanh: Encourage everyone to bring their requirements to the list. 06:21:41 dom: People that have ideas, write them down. 06:22:04 dom: ...related to existing use cases. 06:22:31 dom: I will be pushing back strongly on anything that requires a completely different API to the one we have now. 06:22:39 Zakim, reopen the queue 06:22:39 ok, dom, the speaker queue is open 06:22:41 dom: But there is room for some small API changes. 06:22:53 q+ 06:24:33 if something is mandatory, and the browser can't do it, does the browser give you an error that the constraints can't be satisfied or just silently ignore the constraint. 06:24:33 if something is optional, and the browser can satisfy that, can the browser just ignore the constraint 06:25:25 gmandyam: Tobie's manifest on mobile dev. e.g. LinkedIn using browser sniffing to detect capabilities. This will happen. 06:25:34 Zakim, ? 06:25:34 I don't understand your question, dom. 06:25:37 gmandyam: Let's not think we can avoid that happening. 06:25:37 q? 06:25:44 ack gmandyam 06:25:48 q+ 06:26:21 Travis: Looking at constrainable interface at the 'settings'. Is that defined anywhere? 06:26:28 burn: may be a problem with that link. 06:26:42 JimBarnett: settings is not defined Constrainable? 06:26:57 adambe: the link doesn't work due to a doc bug 06:27:06 Travis: So it's like a representation of one or more properties any their values? 06:27:10 JimBarnett: it represents the current values of the properties 06:27:23 ... defined in 10.1.3 06:27:32 s/any their values/ans their values/ 06:27:42 s/ans their values/and their values/ 06:28:09 Settings needs an IDL spec 06:28:43 burn: Preference may be given ultimately to proposals that don't change our entire understanding of how the mechanisms work. 06:28:50 burn: How far that extends is a subjective call. 06:29:10 dom: Rephrasing: my interest is in shipping not just the spec. 06:29:22 dom: So what proposal will get this thing shipping sooner? 06:29:48 dom: If something is supported by browser vendors then that may carry more weight. 06:30:01 dom: Since that means we will be shipping sooner. 06:30:06 +1 06:30:32 burn: Lot's of descriptions how this thing should work. There are some expectations out there already on how this should work. 06:30:49 dom: If browser makers get pushback from developers then we may hear about it. 06:30:54 ack jib 06:30:55 ack jib_ 06:31:30 dan: not convinced that implementers always know best what developers expect 06:32:15 jib: are we going to discuss permissions? 06:32:19 burn: Would be better to discuss the permissions stuff first. 06:32:32 jib: can we discuss permissions with gUM and the exploit of using mandatory constraints to play 20 questions to discover your cam info? 06:32:33 stefanh: Let's move on. Discuss permissions first. 06:33:17 Topic: Permissions 06:33:39 burn: Which permissions are available at which point in the permissions check. 06:33:48 maltman has joined #mediacap 06:33:59 Travis: we should start with what the spec says. 06:34:23 burn: API method is now called getMediaDevices(...) 06:35:13 http://dev.w3.org/2011/webrtc/editor/getusermedia.html#methods-2 06:36:48 q+ 06:38:28 silvia: background on what chrome implements re: label attribute... 06:38:34 silvia: label is an empty string over http but exposed over https. 06:38:52 burn: suspect that's a consequence of being able to save http-based pages but not https-based pages. 06:39:16 fluffy: reasons we got to that is because we're trying to avoid fingerprint stuff. 06:39:27 fluffy: This all goes back to the fingerprinting and whether we can prevent that or not. 06:39:37 stefanh has joined #mediacap 06:39:51 burn: With the way the spec is written right now - fingerprinting info can show up in the label attribute if you have accomplished a prior permissions check. 06:40:14 burn: Very important distinction about 'before permission granted' and 'after permission granted'. 06:40:38 silvia: In Chrome, I only get the label after permission check on HTTPS only. 06:41:16 burn: Believe this is the only info you can get. 06:41:38 I ran MediaStreamTrack.getSources(function(result) {console.log(result);}); in the console of chrome 31 06:41:51 JimBarnett: You can get the capabilities of an object after permissions are granted. 06:41:52 on both http and https I don't get labels 06:42:12 I will only get labels after I have once been successful at getting a camera in https 06:42:35 q? 06:42:49 q- 06:42:52 burn: situation today is that you can only get the capabilities after you're acquired permission to access that device. 06:43:42 jib_: How about calling getUserMedia() with every single possible constraint. Then it fails and re-invoke gUM each time, removing one constraint at a time, until it works. 06:44:12 jib_: So I can figure out what the capabilities are before permission is granted. 06:44:33 dom: Another requirement for mandatory constraints may be 'do not leak information about the device'. 06:45:23 q+ 06:45:59 Travis: one use case I've seen requested is to avoid the permissions prompt at all since there's things you can discover from a constrainable interface 06:46:21 q+ 06:46:26 Travis: Is that a requirement we must satisfy or do we need to put permissions first. 06:46:56 q+ 06:47:08 jib_: What I proposed on the list is to remove the error for when something is overconstrained and instead always bring up the permission prompt. 06:47:44 ack fluffy 06:47:57 dom: We need to go through the queue but you are well placed to bring this up for more discussion on the list. 06:48:22 s/this up/up this as a requirement/ 06:48:25 fluffy: We had previously come to the conclusion that the info available was slightly different depending on whether you had permission or not. 06:49:54 burn: we also realized that there is already so much fingerprinting info available already that this does not really add that much more info. 06:50:02 [I think the requirement we want to consider for mandatory constraints is "mandatory constraints must not enable to leak information about the hardware set up before the user has granted permission to one such device] 06:50:11 s/]/"]/ 06:50:25 q+ 06:50:56 ack burn 06:51:28 burn: We want to close the gap with native and therefore developers need to know things before they start setting up the camera. 06:51:33 why would you install a 3d app on a device without a 3d camera? 06:51:38 Certainly is seems per previous conversation that's possible in the persistent permission case 06:52:10 q? 06:52:22 Teh question is can a non-persistent (or already-permitted) app can query that 06:53:04 silvia: About competing with native apps. They use up-front permissions. Ask once and then I get all permissions up-front. 06:53:19 silvia: Could we have something similar on e.g. first getUserMedia() request from a page? 06:53:44 silvia: If I'm on a dodgy web page, then perhaps that's the point I can leave. 06:54:26 dom: A lot of this is the browsers decision on how to enforce/obtain user's preferences. 06:54:47 dom: The spec can't say much on this other than this step requires user permission. 06:55:07 jib_: The Android permission model has been shown to be ineffective. 06:55:14 q+ 06:55:19 [this is a rathole; permissions on the Web is an unsolved issue] 06:55:19 jib_: No one reads it. The android model doesn't work. 06:55:53 jib_: Understand the use case of the web page that wants to know everything about the web page for full UX control. 06:55:57 q+ what do you mean by "it doesn't work?" 06:56:05 jib_: But there's a reason we need to ask for use permission still. 06:56:06 q+ 06:56:25 jib_: Isn't the whole point of constraints that we don't need to get all the capabilities of the devices up-front? 06:56:25 q- 06:56:32 <5 minutes away from the break> 06:56:51 Zakim, close the queue 06:56:51 ok, dom, the speaker queue is closed 06:56:58 ack fluffy 06:57:16 fluffy: Certain argument to be made that Android and iOS permission models are the most successful ever. 06:57:27 ack me 06:57:28 android and apple want the user's information, so yes = successful 06:57:42 fluffy: Lots of people would like to grant persistent, long-term permissions. 06:57:57 fluffy: I suspect the outcome of that discussion won't change from previous discussions. 06:59:03 silvia: There's a different between web sites I trust and web site that I don't. 06:59:29 silvia: And I make my decisions based on that. 07:00:03 dom: Lot's of other discussion elsewhere on this in W3C. Applies to things other than camera access also. 07:00:24 dom: My position: only limited information should be available without permission. 07:00:59 dom: question that has emerged is. does the mechanism for mandatory constraints have or not have the ability to protect this information sufficiently? 07:01:14 FWIW .. my view is it should not leak extra info if it does not have the info 07:01:26 q? 07:01:48 07:02:59 -jesup 07:03:02 -jib 07:12:15 -Taishan 07:27:43 Travis has joined #mediacap 07:30:32 dom has joined #mediacap 07:31:01 dom_proj has joined #mediacap 07:31:07 Zakim, call taishan 07:31:08 ok, dom; the call is being made 07:31:08 +Taishan 07:31:54 -Taishan 07:32:03 Zakim, call taishan 07:32:03 ok, dom; the call is being made 07:32:05 +Taishan 07:32:39 ddavis has joined #mediacap 07:32:50 -Taishan 07:33:04 Zakim, call taishan 07:33:04 ok, dom; the call is being made 07:33:06 +Taishan 07:34:15 Scribe: Travis 07:34:18 q+ 07:34:18 ScribeNick: Travis 07:34:23 Topic: Extensibility and Registry 07:34:26 I can't really hear 07:34:31 Zakim, reopen the queue 07:34:31 ok, dom, the speaker queue is open 07:34:39 getting better 07:34:42 Zakim, who's on the call? 07:34:42 On the phone I see Taishan, Jim_Barnett, fluffy 07:34:43 Taishan has gmandyam, adambe, richt, Travis, silvia, DanD, stephane, alexandreG, dom, burn, stefanh 07:35:09 Topic: IANA Registries 07:35:26 burn: We wanted to allow for extensible constraints that don't require revving the doc. 07:35:31 ... lots of options 07:35:41 http://tools.ietf.org/html/draft-burnett-rtcweb-constraints-registry-04 07:35:49 ... we have some constraints in the doc for convenience 07:35:55 ... It's not perfect. 07:36:06 ... should survive ~5 months due to a recent update. 07:36:10 q+ to ponder if the registration convenience is not hiding the true cost of adding new properties 07:36:17 ... we need to consider more constraints eventually (yep) 07:36:34 ... don't want to have to get webRTC together just to update constraints. 07:36:47 ... I want to hear why IANA is not a good place 07:37:01 gmandyam: registry + expert review? 07:37:02 q+ 07:37:13 burn: You must define Policy + registry 07:37:39 ... current "expert review" 07:37:44 ... can't just way "good value" 07:37:54 Sorry for jumping the queue - just wanted burn to clarify before we move on. 07:37:55 ... need to get the expert to agree that the definition is sufficient 07:38:15 dom: worry about IANA is that it's convenient for editors (of the spec) but hides from impementors 07:38:40 ... any process applied to the registry would be duplication of W3C process 07:38:41 q+ 07:38:51 s/current "expert review"/currently "specification required with expert review"/ 07:38:56 ... process is there to help make sure the definitions make sense. 07:39:19 ... seems like the potential shortcut for extensibility doesn't become a problem. 07:39:31 ... not so familiar with IANA reg. proces,.. 07:39:55 ... but think about W3C specs as giant registry, etc. (in the abstract) 07:40:10 q+ 07:40:17 ... not pushing back very strongly, but... 07:40:46 ... seems more like WebIDL dictionary keys or Enum, and could look to make spec easier to update 07:40:53 ack dom 07:40:53 dom, you wanted to ponder if the registration convenience is not hiding the true cost of adding new properties 07:41:03 +jesup 07:41:04 ... splitting these out into a separate process/community could cause more issues. 07:41:06 ack me 07:41:28 silvia: registrys have been talked about a lot in HTML. 07:41:35 s/ys/ies/ 07:41:46 ... let's be aware of some of the problems and make a concous decisions. 07:41:54 ... 1) IANA may not move as quickly 07:42:04 ... 2) may take longer to update than in reality 07:42:24 q+ 07:42:31 ... (example of 3d camera constraint which gets implemented, but lags in the IANA) 07:42:33 q+ to comment on HTML registries comparison 07:42:39 ... in WHATWG they use Wiki approach 07:42:55 ... open to public, public mentions it there. 07:43:10 ... not advocating IANA or Wiki-based approach 07:43:26 ... formal registries have slowness. There are some advantages and disadvantages 07:43:37 ack silvia 07:43:49 fluffy: I will explain IANA registries 07:44:09 ... this is an IETF thing, and they can help 07:44:33 ... can make a difficult approval process (one approach) 07:44:43 [but then isn't the registry a duplication of a W3C spec?] 07:44:55 ... likely what they want is a wiki-like registry (to ensure uniqueness of names--basically) 07:45:43 -Taishan 07:45:48 Zakim, call taishan 07:45:48 ok, dom; the call is being made 07:45:50 +Taishan 07:47:07 fluffy: these are very quick. 07:47:41 ... what we want--everyone provides a link to a doc w/explainer and the result is a name 07:48:05 q+ to also comment on similar name-appropriation issues and solutions in w3c 07:48:08 ... our group can select names that are unique 07:48:32 Dona not hearing you all that well 07:48:43 ack fluffy 07:48:45 ack burn 07:48:51 burn: plugs for fluffy as an IANA expert 07:49:14 burn: I've talked with other W3C groups about registries 07:49:50 ... reason for IANA was that sometimes groups can last awhile, but expertise can come and go. 07:49:58 ... remaining connected via a registry is very lightweight. 07:50:04 hearing dan fairly well now 07:50:21 q+ 07:50:32 ... the thinking was that we'd get better response via a registry, than keeping a WG alive 07:50:48 kazho_ has joined #mediacap 07:50:52 q+ 07:50:59 ack gmandyam 07:51:23 gmandyam: for timely additions to registry additions, seems like it's related to vender prefixed 07:51:44 ... we should go slow when a non-prefixed form (general use) is proposed. 07:52:01 ... we may need both slow and fast track in the registry 07:52:13 q+ to ask how long it typically takes to add something to a registry at IANA 07:52:14 ... I understood that expert review assured that this was possible. 07:52:24 ... not sure if expert review will work with IANA registry 07:52:33 burn: expert review can be done however we want. 07:52:49 ... we can relay instructions to the expert review to help manage the process 07:52:54 ack me 07:52:54 dom, you wanted to comment on HTML registries comparison and to also comment on similar name-appropriation issues and solutions in w3c 07:52:54 ... (can make it quick) 07:53:31 dom: registries in HTML are for places where developers can innovate, not for stuff that browsers depend on. 07:53:44 ... meta names and rel values 07:53:58 q+ to ask about testing 07:54:16 ... for registry of constraints, seems more like CSS properties, which WG has been around a long time (to service property requests) 07:54:42 ... the CSS "expert review" gaurantees that they fit into the CSS model 07:54:57 ... vender prefixes have come out of vogue. 07:55:16 ... now they are released behind opt-in flags 07:55:27 ... my view is that our situation is more like CSS 07:56:03 +jib 07:56:04 ... personal opinion: IANA registry doesn't add same level of value as WG managed "list" 07:56:13 ... what worries me the most: 07:56:13 q? 07:56:34 ... these are for interoperable constraints that browsers need to ship--and related complications, bugs, etc. 07:56:53 ... registry is so "easy" that we'll get unmanagable proposals, no interop, etc. 07:57:06 ... if that's the end result, then we fail our mission. 07:57:15 ... yes, there's a cost, but it comes from the requirement to get interop 07:57:24 burn: can you compare to a wiki? 07:57:36 dom: yes, great for feature ideas, and open to the public 07:57:47 ... but browsers don't need to ship these. 07:58:15 ... some constraint (fake) is proposed, but browsers may never ship it. 07:58:25 ack stefanh 07:58:35 stefanh: same general thoughts as DOM 07:58:43 s/DOM/Dom 07:58:46 q+ 07:58:53 ... things to make mandatory for browsers shouldn't just be "listed" 07:59:05 richt: Q: 07:59:18 ... is it as simple as just coming up with a new constraint? 07:59:32 ... does our spec just handle that? 07:59:42 dom: This is kinda the problem I was saying. 08:00:04 ack DanD 08:00:10 ... in some cases in CSS you come with a variety of design options. Assuming a constraint is exactly what you want may be coming from the wrong perspective. 08:00:27 DanD: May have a chicken/egg problem 08:00:32 +1 dom 08:00:46 ... we could consider how much volume of things we want to take on. 08:00:53 ... how much value, discussions, etc. 08:01:04 ... would be nice to know what the expected scale will be 08:01:10 ... we really don't know yet. 08:01:28 ... perhaps we can base our decision after we get more traction 08:01:36 ... maybe we could try a 2-step process 08:01:36 q+ to comment on SSML success because no group had to hang around all this time 08:01:42 ... there are options here. 08:02:01 ... I see these as a fairly static collection of properties. 08:02:08 ... hope we don't add/remove every week. 08:02:34 ack silvia 08:02:34 silvia, you wanted to ask how long it typically takes to add something to a registry at IANA 08:02:35 ... if there's an early settlement of constraints, perhaps we start with a more collaborative process then change. 08:02:50 silvia: Seems like implementation speed isn't much of a concern here. 08:03:01 ... but rather, when 2 browsers implement, there is some formal registration 08:03:15 ... prior to that, a wiki may be enough (list of experimental constraints) 08:03:30 ... if two browsers agree then perhaps IANA kicks in, or the WG looks at it. 08:03:41 ddavis has joined #mediacap 08:03:46 ... considering IANA: name added to list, and done 08:03:51 ... if that's it then fine. 08:04:04 ... if not, e.g., there may be side-effects, other definitions... 08:04:10 ... then it's not just a registry. 08:04:20 ... it's a functional addition and registry is not sufficient 08:04:35 ddavis: Q on testing 08:04:52 ... would be be excluded from a W3C test suite if it was in a registry? 08:04:56 ack ddavis 08:04:56 ddavis, you wanted to ask about testing 08:04:57 ack fluffy 08:05:05 dom: That's to my point--it should be part of the WG process 08:05:29 fluffy: may be confusing process of making a standard and registry list. 08:05:31 fluffy, but that's also what W3C specs are 08:05:43 ... you can define what you want the process 08:05:52 ... it will never be the "required to implement" list 08:06:00 dom, the defined process for the registry can say to find or re-create a W3C group to discuss, if necessary 08:06:05 ... may find that community invents new interesting things 08:06:19 sure, but then what does it bring on top of just saying nothing (i.e. new values get added by updating the spec)? 08:06:42 ... want to clarify our range of options. 08:06:53 ... clarify 08:06:55 ... more clear 08:07:06 dom: yes, a point to understand. 08:07:06 ack me 08:07:06 burn, you wanted to comment on SSML success because no group had to hang around all this time 08:07:20 q+ to ask what Iana would add to W3C spec 08:07:20 burn: want to +1 fluffy 08:07:40 ... it's _long lived_ (years and eons) 08:07:51 ... process can define what to do with entries 08:08:21 ... thinking about a group (that is gone), successfully left an expert reviewer with the possibility of even re-starting a WG. 08:09:07 ... registry documents have processes to handle this sort of thing (maintenance and what to do) 08:09:23 dom: Then why aren't we doing IANA for CSS? 08:10:10 dom: since there's no need to create new entries in the registry, then there doesn't seem to be a need to keep the group around 08:10:41 q+ 08:10:58 ... you can always ask W3C directly to re-start a group if you want. 08:11:31 ... seems like the same effect as having IANA redirect to W3C. 08:11:36 ... just not quite seeing the value 08:12:11 burn: left out the piece that if it's a small item, then it can be resolved rapidly through the expert. 08:12:33 dom: key question is mandatory constraints 08:12:56 ... browser vendors will want interop. An IANA registry wouldn't likely be able resolve. 08:13:01 q? 08:13:15 ... others are just "optional" constraints (may not need) 08:13:18 ... also 08:13:23 ack dom 08:13:23 dom, you wanted to ask what Iana would add to W3C spec 08:13:30 ... extensibility will come from all angles. 08:13:54 ... 3D cameras (when they come on the scene) will need much more than a constraint def. 08:14:06 ... may need much more for proper exposure to the web 08:14:11 -jib 08:14:25 burn: both processes support discussion in a working group. 08:14:30 q+ to point out that we don't have to resolve this today 08:14:39 ack fluffy 08:14:43 dom: skeptical that the expert review being able to decide 08:14:58 +jib 08:15:28 fluffy: mandatory constraint doesn't mean mandatory to implement, just that browsers need to error when not supported. 08:15:43 q+ 08:15:53 dom: understand, but we don't have interop if they're not interoperable in the browser 08:16:02 fluffy: Let's talk CSS 08:16:07 ... people want to move quickly. 08:16:46 ... implementers just throw out css vendor prefixed stuff willy-nilly 08:17:11 dom: CSS has learned valuable lessons 08:17:16 ... they've improved their processes to manage this. 08:17:23 fluffy: educate me 08:17:41 dom: I only have so much experience here... 08:18:00 ... but I've heard that browser experimental features will operate behind a flag. 08:18:04 wonsuk has joined #mediacap 08:18:29 silvia: ... then as 2 implements do the same thing, then it becomes "official" and gets a standard 08:18:50 fluffy: Yep, seeing features implemented quickly is great. 08:19:03 ... when it takes too long people move to different working groups. 08:19:11 q? 08:19:13 dom: I see a need for flexibility and extensibility 08:20:18 dom: quotes process as a means for making things happen. 08:20:30 ack silvia 08:20:30 silvia, you wanted to point out that we don't have to resolve this today 08:20:32 (lots of arguing) 08:20:45 silvia: if we think of IANA as a wiki 08:20:52 ... then it's overkill 08:21:00 ... we have to deal with 2 standards processes 08:21:08 ... agree with dom. 08:21:25 ... if we just need an experimental name sandbox 08:21:34 ... see the point for when the WG is dead 08:21:53 +1 to silvia 08:21:59 ... should be easy to add something to the tail of a doc in a registry 08:23:01 dom: Let's get this done. We can definately set up what we need to do. 08:23:15 ack me 08:23:36 q+ 08:23:48 silvia: some browsers may just start doing something and it becomes de-facto standard 08:23:57 ack DanD 08:23:59 DanD: could the list be used in other context? 08:24:05 ... just saying.. 08:24:20 burn: Wrote a first draft. Not sure what would go into the registry. 08:24:25 ... lots of open issues 08:24:49 DanD: if it applies to more than just constraints, then seems valuable 08:24:53 ack ddavis 08:25:04 ddavis: CSS works in modular fashion. Lots of small specs 08:25:08 q+ 08:25:12 ... seems like you could work the same way. 08:25:25 Travis: WebPerf is another example 08:25:34 ... they created an entire spec that defined a single property 08:25:40 ... it only took them 6 months to go to Rec 08:25:44 ... (hirestime) 08:25:50 ... there are also community groups 08:25:57 ... a variety of options to get things done quickly 08:26:06 ack me 08:26:07 ack burn 08:26:19 burn: I see this living either place. I've seen both ways. 08:26:32 ... I tried very hard to keep things in W3C 08:26:48 ... there was previous confusion about how things would work in W3C 08:26:57 ... just saying we should put it in the right place. 08:27:07 ... if you're not familiar with IANA registries. 08:27:11 [I think I've argued why W3C seems like the right place, independently of IANA] 08:27:16 ... then go learn about it. 08:27:37 fluffy: IANA is not part of IETF incase folks didn't know. 08:27:38 q+ 08:27:48 Zakim, close the queue 08:27:48 ok, dom, the speaker queue is closed 08:28:02 silvia: Wanted to suggset that wiki page is a great idea no matter what the outcome here. 08:28:14 ... we need a place to germinate ideas. 08:28:18 ... (for browsers) 08:28:31 ... recommend putting a link into the spec for new feature ideas 08:28:46 ... we can then take it from there depending on what happens 08:29:57 ... seems OK to link to a wiki page from the spec (as long as it's non-norm.) 08:30:05 dom: We also need to hear from browsers. 08:30:19 ... they know how much they are expected to innovate 08:30:40 silvia: Browsers can't see the future; this is for extensibility 08:31:54 Dom: it would be good to know what implementors think they see as likely need for extensibility and in what timeframes 08:32:03 ... clearly they have an important say on the need for this 08:32:28 stefanh: Let's do some agenda bashing again... 08:32:36 burn_ has joined #mediacap 08:35:09 stefanh: We had a discussion about media streams, tracks, etc. 08:35:30 ... largely agreement on changes proposed by adam 08:35:39 ... then we discussed constraints 08:35:46 s/media streams/lifecycle of media streams/ 08:35:47 ... there was concensus about needing them 08:35:54 s/conc/cons/ 08:36:08 ... we didn't agree on all the requirements, but we saw a need to review requirements 08:36:49 ... there were some actions on the chairs, and some ideas are floating around that should have more list discussion 08:37:00 ... then a long discussion on the IANA registry 08:37:20 ... determined that we don't need to decide it now 08:37:26 q+ 08:37:30 OK 08:37:41 dom: per fluffy we need to figure this out before LC 08:38:24 ... we don't yet have concensus on the approach 08:38:30 richt: can we do nothing? 08:38:44 dom: that means "go back to the WG" 08:39:11 silvia: expecting to close the group? 08:39:20 stefanh: it's a TF, may finish :-) 08:39:34 dom: what we are doing here is of the same scale as CSS/HTML 08:39:49 ... I expect a long lived group because there's a lot of work yet to do. 08:39:55 ... (sorry to disappoint) 08:39:59 Can we set up something in the spec whereby if the group no longer exists it devolves to IANA? ;-) 08:40:37 s/can we do nothing?/what happens if we do nothing and return to W3C for this discussion when extensibility actually happens or is needed?/ 08:41:35 Zakim, reopen the queue 08:41:35 ok, dom, the speaker queue is open 08:41:57 gmandyam: parting thoughts--IANA's already in the spec and working? pundits can object via the list 08:42:57 ACTION: Dom to come back to media capture list on alternative proposal for registring constraints 08:42:57 Created ACTION-28 - Come back to media capture list on alternative proposal for registring constraints [on Dominique Hazaël-Massieux - due 2013-11-21]. 08:43:19 fluffy: dom please propose alternatives to list 08:43:29 stefanh: we didn't discuss noaccess/identity 08:43:34 ... this is an issue for LC 08:44:02 dom: from this morning's discussion, seems like noaccess/peerIdentity are poor fits for constraints 08:44:06 q+ 08:44:12 stefanh: Yes, agree. 08:44:12 q- 08:44:16 ack burn_ 08:44:23 q? 08:45:11 stefanh: ready to push integration with web messaging to v2 08:45:25 ... nothing to say about testing status (skipped) 08:45:30 dsinger has joined #mediacap 08:45:40 burn_: on noaccess/peerIdentity (NO/PI) 08:45:46 -> https://www.w3.org/Bugs/Public/show_bug.cgi?id=22594 Bug 22594 - noaccess / peerIdentity as constraints 08:46:23 ... important to consider which portions of NO/PI belong in MCAS vs. WebRTC specs 08:46:54 ... editorially, we have largely tried to avoid PeerConn. in MCAS. 08:46:55 +1 to burn 08:47:04 ... we need to look at this 08:47:29 fluffy: Let's have the WebRTC guys sort out. 08:47:43 ... don't think we should go as far as removing 08:47:57 gmandyam: Argues that they slipped in when they shouldn't ahve 08:48:16 fluffy: Do we use the constraint mechanism to handle these? 08:48:34 ... but we know we're going to have this capability. 08:48:39 ... we've always known 08:49:26 dom: Yep, we should sort out where these live, how they're integrated, and where they need to be defined 08:49:43 There may be long-standing agreement to include a PeerIdentity mechanism in the WebRTC context, but not necessarily in the Media Capture context. 08:49:50 fluffy: WebRTC = martin + ekr 08:49:59 gmandyam, fair point as well, indeed 08:50:21 stefanh: LC for dec. 6 seems unrealistic 08:50:37 ... (since I have call to discuss requirements on constraints) 08:50:51 burn_: Hey, we're making progress via these discussions 08:50:54 q+ 08:50:57 q+ 08:51:25 stefanh: when should we plan to finish 08:51:26 ? 08:51:31 ack fluffy 08:51:47 fluffy: The hard things: access, per-machine, identity, etc. 08:52:08 s/per-machine/permission/ 08:52:16 ... we are trying to land this spec with these hard problems 08:52:17 +1 to fluffy on scoping down 08:52:21 ... folks, go review the spec 08:52:32 ... does it have everything you think it needs? 08:52:49 ... browsers are moving forward, they may not want to reset (again, and again) 08:52:56 ... what are the things that really need to change? 08:52:59 dom: +1 08:53:05 ... we need to prioritize 08:53:47 stefanh: in WebRTC, we put out the option to divide and conquer 08:53:53 ... perhaps we can consider that? 08:53:57 q+ 08:54:01 dom: A complex problem. 08:54:18 ... may be something for me and chairs to discuss 08:54:26 ... clarifing... 08:54:40 ... my philosophy w/ standards is what ships and has interop 08:54:49 ... good spec helps meet those goals 08:55:10 ... we need to understand and build consensus on what is/will ship and what is interoperable 08:55:22 ... there are some non-interoperabilities 08:55:27 ... we know mostly how to solve these. 08:55:34 ... we should take input from everyone 08:55:41 ... we collected it all and call it MCAS 08:55:52 ... we need to continue thinking about the hard problems 08:56:11 ... people seem to think about v2's as not happening... 08:56:22 ... think more about it as modules that run in parallel. 08:56:36 ... we run in cycles getting things to interop and moving on and iterating. 08:57:02 ... given where implementations are, the idea of not finishing soon gives me despair 08:57:19 ... it's a most difficult problem 08:57:30 burn_: I think we're much closer than what fluffy said. 08:57:32 q? 08:57:35 ack me 08:57:40 ack jesup 08:57:46 ... I'm feeling encouraged as a result of various conversations I've heard. 08:58:08 jesup: I also think we're close 08:58:47 ... part of discussing and working through the issues is because folks have started to implement. 08:59:01 ... we're now getting the implmentation feedback. 08:59:15 ... we're moving in the right direction. 08:59:22 +1 to jesup 08:59:24 +1 08:59:24 ... we should be careful not to open up too much... 08:59:53 ... we're driving toward finalizing. 09:00:21 gmandyam: I have an image capture presentation on the wiki. 09:00:35 ... want to raise a few points before people leave (or fall alseep) 09:00:40 Topic: Image Capture input on constraints 09:00:59 -> http://lists.w3.org/Archives/Public/www-archive/2013Nov/att-0009/Image_Capture_spec_update_November_2013.pdf Giri's slides 09:01:06 gmandyam: on slide 2 09:02:26 gmandyam: To be useful for mobile devices, want to add focus and zoom 09:03:42 ddavis has joined #mediacap 09:04:02 ... my problem without a registry, is that someone adds zoom/focus and conflicts with what's in my spec 09:04:19 travis: browsers just won't go implement what's in a registry/wiki page. 09:05:00 gmandyam: 2nd thing: slide 4 09:05:07 ... camera preview 09:05:40 ... today we have kind=video or audio 09:05:53 ... previews may be done off the same track, but there's another idea. 09:06:06 ... you could create a preview by frame grabbing. 09:06:20 ... not ideal, but what FirefoxOS does--and doesn't like it 09:06:30 q+ to ask how we are dealing with settings like focus 09:06:54 ... think I can propose a preview track. 09:07:10 ... without constructors being a problem, I'm not as scared. 09:07:19 jesup: can you detail the constructors issues. 09:07:21 ? 09:07:46 gmandyam: harald proposed removing the types/constructors 09:08:34 q- 09:08:41 ... will put together a proposal 09:08:57 adambe: is there a relationship to cloning? 09:09:11 travis: I'm not sure i'm enough up on the issues. We only implemented MSTs relatively recently, and don't support constructors for them yet IIRC (jib_?) 09:09:39 jesup: I'm at a loss too. 09:09:42 ? 09:10:08 Some discussion is going over my head 09:10:40 gmandyam: now on slide 6 -- going toward promises. 09:11:13 s/travis:/travis, 09:11:17 s/jesup:/jesup, 09:11:50 richt: how do feel about consistency with gUM 09:12:14 gmandyam: community seems in support of promises 09:12:26 fluffy: please take it to the list. 09:12:45 ... also, we may have made a mistake about promises 09:13:22 RRSAgent, draft minutes 09:13:22 I have made the request to generate http://www.w3.org/2013/11/14-mediacap-minutes.html dom 09:13:25 -fluffy 09:13:26 -jib 09:13:27 4:13am ET here 09:13:30 -Taishan 09:13:34 -Jim_Barnett 09:13:42 -jesup 09:13:43 UW_MdCap()7:00PM has ended 09:13:43 Attendees were +1.403.244.aaaa, fluffy, jib, jesup, Jim_Barnett, gmandyam, adambe, richt, Travis, silvia, DanD, stephane, alexandreG, dom, burn, stefanh, Taishan 09:16:47 dsinger has joined #mediacap 09:48:05 dsinger has joined #mediacap 09:48:14 dsinger has left #mediacap 09:54:41 silvia has joined #mediacap 10:19:58 ddavis has joined #mediacap 10:39:44 lgombos__ has joined #mediacap 11:02:44 lgombos__ has joined #mediacap 11:32:49 Zakim has left #mediacap