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
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]
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]
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]
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:
01:04:41 [gmandyam]
Stefan: Minutes approved.
01:04:48 [dom]
-> Agenda
01:05:02 [gmandyam]
Stefan: Agenda bashing ...
01:05:07 [jesup]
jesup has joined #mediacap
01:06:20 [Zakim]
01:06:24 [gmandyam]
Stefan: Will cover Image Capture and Recording towards end of meeting if time permitting
01:06:51 [silvia]
01:06:54 [fluffy]
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]
-> 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]
-> (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]
-> 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]
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]
-> 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]
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]
-> 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]
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]
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]
01:35:11 [dom]
q+ richt
01:35:39 [dom]
ack gmandyam
01:36:26 [jib_]
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]
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]
01:39:18 [gmandyam]
richt: This is a "first world" type of approach.
01:39:29 [dom]
ack jib
01:40:05 [JimBarnett]
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_]
01:41:44 [Travis]
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]
01:43:57 [dom]
ack JimBarnett
01:44:11 [JimBarnett]
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]
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]
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]
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]
01:55:48 [dom]
ack adambe
01:55:52 [stefanh]
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]
01:58:58 [Travis]
01:59:12 [DanD]
01:59:24 [gmandyam]
burn: (Slide 9) Describes difference between capabilities, constraints, settings
01:59:28 [silvia]
01:59:31 [gmandyam]
02:00:20 [jesup]
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]
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]
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]
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]
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]
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]
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]
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]
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]
02:25:21 [adambe]
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]
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]
02:28:15 [jib_]
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]
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]
02:32:39 [dom]
ack jib_
02:33:30 [Zakim]
02:33:53 [dom]
ack JimBarnett
02:33:54 [fluffy]
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]
02:34:44 [Zakim]
02:34:48 [jib_]
02:35:18 [dom]
Zakim, close the queue
02:35:18 [Zakim]
ok, dom, the speaker queue is closed
02:35:32 [fluffy]
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]
02:38:12 [Zakim]
02:38:19 [jib_]
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]
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_]
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]
02:42:44 [Zakim]
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]
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]
03:11:16 [dom]
Zakim, call taishan
03:11:16 [Zakim]
ok, dom; the call is being made
03:11:17 [Zakim]
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]
03:12:54 [dom]
Zakim, call taishan
03:12:54 [Zakim]
ok, dom; the call is being made
03:12:55 [Zakim]
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]
03:17:49 [gmandyam]
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]
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]
03:20:24 [dom]
burn: yes
03:20:26 [silvia]
03:20:29 [fluffy]
03:20:31 [gmandyam]
ack gmandyam
03:20:35 [JimBarnett]
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]
03:21:14 [silvia]
03:21:17 [kazho]
kazho has joined #mediacap
03:21:21 [dom]
03:22:50 [burn]
03:22:59 [silvia]
03:23:14 [dom]
jesup: ok; that might be hard to test
03:23:35 [gmandyam]
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]
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]
03:26:20 [dom]
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_]
03:28:36 [fluffy]
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]
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]
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]
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]
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]
-> 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
03:39:48 [trackbot]
Created ACTION-25 - Switch mediastream.inactive to [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]
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]
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]
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]
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]
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]
03:52:29 [dom]
... [slide 6 "Proposal"]
03:52:37 [dom]
ack jesup
03:52:37 [jesup]
ack jesup
03:52:54 [gmandyam]
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]
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]
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]
03:55:32 [Zakim]
03:55:43 [Zakim]
03:55:45 [Zakim]
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]
05:30:00 [dom_proj]
dom_proj has joined #mediacap
05:30:01 [Zakim]
05:30:01 [Zakim]
05:30:10 [dom]
Zakim, call taishan
05:30:10 [Zakim]
ok, dom; the call is being made
05:30:11 [Zakim]
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]
05:31:02 [dom]
Zakim, call taishan
05:31:02 [Zakim]
ok, dom; the call is being made
05:31:04 [Zakim]
05:31:04 [Zakim]
05:31:47 [Zakim]
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]
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]
05:34:01 [jesup]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
05:56:06 [fluffy]
05:56:08 [dom]
ack burn
05:56:09 [fluffy]
05:56:13 [Travis]
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]
06:01:19 [fluffy]
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]
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]
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]
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_]
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]
06:10:14 [richt]
silvia: Want to point out a someone having used constraints in an app with 3 cameras...
06:10:18 [Zakim]
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]
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]
06:12:05 [richt]
silvia: I think we're discussing on different levels.
06:12:21 [fluffy]
06:12:24 [fluffy]
06:12:25 [burn]
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_]
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]
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]
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]
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]
06:25:44 [dom]
ack gmandyam
06:25:48 [jib_]
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]
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]
06:36:48 [fluffy]
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]
06:42:49 [fluffy]
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]
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]
06:46:26 [richt]
Travis: Is that a requirement we must satisfy or do we need to put permissions first.
06:46:56 [silvia]
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]
06:50:25 [jib_]
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]
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]
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]
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_]
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]
07:01:48 [richt]
<break. meeting resumes again at 15:30>
07:02:59 [Zakim]
07:03:02 [Zakim]
07:12:15 [Zakim]
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]
07:31:54 [Zakim]
07:32:03 [dom]
Zakim, call taishan
07:32:03 [Zakim]
ok, dom; the call is being made
07:32:05 [Zakim]
07:32:39 [ddavis]
ddavis has joined #mediacap
07:32:50 [Zakim]
07:33:04 [dom]
Zakim, call taishan
07:33:04 [Zakim]
ok, dom; the call is being made
07:33:06 [Zakim]
07:34:15 [dom]
Scribe: Travis
07:34:18 [burn]
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]
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]
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]
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]
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]
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]
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]
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]
07:45:48 [dom]
Zakim, call taishan
07:45:48 [Zakim]
ok, dom; the call is being made
07:45:50 [Zakim]
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]
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]
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]
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]
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]
07:58:46 [fluffy]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
08:37:30 [gmandyam]
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_]
08:44:12 [Travis]
stefanh: Yes, agree.
08:44:12 [silvia]
08:44:16 [dom]
ack burn_
08:44:23 [stefanh]
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]
-> 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]
08:50:57 [dom]
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]
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]
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]
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]
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]
-> 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]
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]
09:11:17 [dom]
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 dom
09:13:25 [Zakim]
09:13:26 [Zakim]
09:13:27 [jesup]
4:13am ET here
09:13:30 [Zakim]
09:13:34 [Zakim]
09:13:42 [Zakim]
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