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