14:44:00 <RRSAgent> RRSAgent has joined #mediacap
14:44:00 <RRSAgent> logging to http://www.w3.org/2013/05/07-mediacap-irc
14:44:02 <trackbot> RRSAgent, make logs public
14:44:02 <Zakim> Zakim has joined #mediacap
14:44:04 <trackbot> Zakim, this will be MCAP
14:44:04 <Zakim> ok, trackbot; I see UW_MdCap()11:00AM scheduled to start in 16 minutes
14:44:05 <trackbot> Meeting: Media Capture Task Force Teleconference
14:44:05 <trackbot> Date: 07 May 2013
14:48:57 <stefanh> stefanh has joined #mediacap
14:52:09 <burn> burn has joined #mediacap
14:53:58 <fluffy> fluffy has joined #mediacap
14:54:37 <Zakim> UW_MdCap()11:00AM has now started
14:54:44 <Zakim> + +1.408.902.aaaa
14:55:38 <gmandyam> gmandyam has joined #mediacap
14:56:09 <Zakim> + +1.858.651.aabb
14:56:19 <gmandyam> Zakim, aabb is gmandyam
14:56:19 <Zakim> +gmandyam; got it
14:56:47 <Zakim> +Dan_Burnett
14:56:58 <burn> zakim, I am Dan_Burnett
14:56:58 <Zakim> ok, burn, I now associate you with Dan_Burnett
14:58:13 <Zakim> +??P8
14:58:35 <Zakim> + +46.1.07.14.aacc
14:58:51 <stefanh> Zakim, aacc is me
14:58:51 <Zakim> +stefanh; got it
14:58:56 <Josh_Soref> Zakim, code
14:58:56 <Zakim> I don't understand 'code', Josh_Soref
14:59:06 <fluffy> Zakim, aaaa is fluffy
14:59:06 <Zakim> +fluffy; got it
14:59:09 <stefanh> josh, code is 6227
14:59:22 <hta> hta has joined #mediacap
14:59:31 <dom> Zakim, code?
14:59:31 <Zakim> the conference code is 6227 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), dom
14:59:38 <Zakim> +[Mozilla]
14:59:42 <hta> zakim, who is on?
14:59:42 <Zakim> I don't understand your question, hta.
14:59:49 <adam> zakim: I am Mozilla
14:59:52 <hta> zakim, who is here?
14:59:52 <Zakim> On the phone I see fluffy, gmandyam, Dan_Burnett, ??P8, stefanh, [Mozilla]
14:59:55 <Zakim> On IRC I see hta, gmandyam, fluffy, burn, stefanh, Zakim, RRSAgent, adam, fjh, dom, Josh_Soref, timeless, trackbot, derf
15:00:06 <Zakim> +Josh_Soref
15:00:06 <hta> zakim, ??P8 is me
15:00:06 <dom> Zakim, [Mozilla] is really adam
15:00:07 <Zakim> +hta; got it
15:00:07 <Zakim> +adam; got it
15:00:11 <Josh_Soref> Zakim, mute me
15:00:11 <Zakim> Josh_Soref should now be muted
15:00:15 <Josh_Soref> RRSAgent, draft minutes
15:00:15 <RRSAgent> I have made the request to generate http://www.w3.org/2013/05/07-mediacap-minutes.html Josh_Soref
15:00:21 <Zakim> +Jim_Barnett
15:00:27 <Josh_Soref> scribe: Josh_Soref
15:00:31 <Josh_Soref> RRSAgent, make logs public
15:00:32 <Zakim> +??P20
15:00:33 <Josh_Soref> RRSAgent, draft minutes
15:00:33 <RRSAgent> I have made the request to generate http://www.w3.org/2013/05/07-mediacap-minutes.html Josh_Soref
15:00:34 <dom> Zakim, ??P20 is me
15:00:34 <Zakim> +dom; got it
15:00:43 <Josh_Soref> chair: hta, stefanh
15:00:49 <Zakim> + +44.190.881.aadd
15:00:51 <Josh_Soref> s/josh, code is 6227//
15:00:56 <Josh_Soref> s/zakim: I am Mozilla//
15:00:59 <Josh_Soref> RRSAgent, draft minutes
15:00:59 <RRSAgent> I have made the request to generate http://www.w3.org/2013/05/07-mediacap-minutes.html Josh_Soref
15:01:26 <Josh_Soref> Zakim, who is on the call?
15:01:26 <Zakim> On the phone I see fluffy, gmandyam, Dan_Burnett, hta, stefanh, adam, Josh_Soref (muted), Jim_Barnett, dom, +44.190.881.aadd
15:01:39 <adam> hta: I hear Adam and Harald so far.
15:01:42 <AndyH> AndyH has joined #mediacap
15:02:38 <Zakim> + +1.650.678.aaee
15:02:45 <Josh_Soref> s/hta: I hear Adam and Harald so far.//
15:03:04 <ekr> ekr has joined #mediacap
15:03:12 <stefanh> agenda: http://lists.w3.org/Archives/Public/public-media-capture/2013May/0002.html
15:03:14 <Zakim> +[Mozilla]
15:03:26 <Josh_Soref> topic: Minutes Approval
15:03:34 <stefanh> http://lists.w3.org/Archives/Public/public-media-capture/2013Apr/0006.html
15:03:52 <Josh_Soref> RESOLUTION: Approve minutes from 25 Mar 2013
15:04:09 <Josh_Soref> Topic: Error handling
15:04:16 <Josh_Soref> s/Topic: Error handling//
15:04:19 <Josh_Soref> Topic: Agenda
15:04:29 <Josh_Soref> fluffy: is there time to discuss facing-mode?
15:04:32 <Zakim> + +1.610.889.aaff
15:04:41 <Josh_Soref> hta: we could put it in AOB
15:04:47 <Josh_Soref> fluffy: i won't be here at the end
15:04:55 <Josh_Soref> hta: we could put it under MC Streams
15:04:58 <hta> s/hta/stefan/
15:05:09 <Josh_Soref> s/hta/stefan/
15:05:14 <Josh_Soref> Topic: Error handling
15:05:38 <Josh_Soref> hta: i'd suggest no changes to what we have
15:05:46 <stefanh> hr
15:05:49 <Josh_Soref> ... the text is still in WebRTC sec 4.6
15:05:57 <stefanh> hta's slides: http://lists.w3.org/Archives/Public/public-media-capture/2013May/att-0019/MediaCapture_error_handling_-_May_preso.pdf
15:05:57 <Josh_Soref> ... i'd suggest we align more closely w/ DOM
15:06:04 <Josh_Soref> ... using DOM defined Errors
15:06:09 <Josh_Soref> ... and DOM defined Error Classes
15:06:22 <Josh_Soref> ... and take the other errors we need and ask they be defined in the DOM spec
15:06:32 <mreavy> mreavy has joined #mediacap
15:06:34 <Josh_Soref> ekr: i'm fine w/ the specific changes here
15:06:38 <Josh_Soref> ... but i'm concerned based on the list
15:06:47 <Josh_Soref> ... i don't think we have as much consensus as we previously thought
15:06:55 <Josh_Soref> ... about what are Exceptions and what are not
15:06:59 <jesup> jesup has joined #mediacap
15:07:04 <fjh> zakim, code?
15:07:04 <Zakim> the conference code is 6227 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), fjh
15:07:14 <Zakim> +[IPcaller]
15:07:17 <Josh_Soref> hta: is it reasonable to have success/failure callbacks
15:07:31 <fjh> zakim, [IPcaller] is me
15:07:31 <Zakim> +fjh; got it
15:07:31 <Josh_Soref> ... there are also errors that aren't immediately accessible
15:07:41 <Josh_Soref> ekr: my assumption is that the current text is correct
15:07:46 <Josh_Soref> ... when looking at an api call
15:07:54 <Josh_Soref> s/my assumption/let's not assume/
15:08:09 <Josh_Soref> ... when deciding whether an exception should be an error or callback
15:08:13 <Josh_Soref> ... we should have a policy for this
15:08:25 <Josh_Soref> ... in this particular case, we need to add exception/error callback
15:08:52 <Josh_Soref> stefanh: the text in 4.6.1
15:09:07 <Josh_Soref> ... was clearly written w/ the understanding that we have error callbacks whereever we want to have them
15:09:11 <Josh_Soref> ... that's the part that is questionable
15:09:13 <Josh_Soref> ekr: yeah
15:09:16 <gmandyam> +q
15:09:32 <Josh_Soref> ... i assumed that. if 4.6.1 is principles
15:09:43 <Josh_Soref> ... then i think it's clear that XXX needs an error callback
15:09:53 <Josh_Soref> ... passing a candidate flag of BOGUS isn't ok
15:09:58 <Josh_Soref> ... it isn't an invalid state
15:10:06 <Josh_Soref> s/XXX/addIceCandidate/
15:10:18 <Josh_Soref> hta: agree, but that's for another section of talk
15:10:28 <Josh_Soref> ekr: paul's document includes a list of policy
15:10:32 <hta> s/hta/stefan/
15:10:33 <Josh_Soref> ... which seems less specific
15:10:41 <Josh_Soref> ... and it seems to contemplate a change to the policy
15:10:50 <Josh_Soref> ack gmandyam
15:10:50 <burn> s/paul's/Harald's/
15:10:55 <fluffy> can folks that are not speaking please mute - we have really bad ech
15:11:12 <dom> Zakim, who's noisy?
15:11:13 <Josh_Soref> gmandyam: there was a discussion on DAP
15:11:23 <Zakim> dom, listening for 10 seconds I heard sound from the following: gmandyam (7%), hta (15%)
15:11:26 <Josh_Soref> ... ML about Errors being sync
15:11:30 <dom> Zakim, mute hta
15:11:30 <Zakim> hta should now be muted
15:11:36 <Josh_Soref> s/Errors/Exceptions/
15:11:42 <Josh_Soref> ... but Errors are async
15:11:48 <Jim_> Jim_ has joined #mediacap
15:11:52 <fjh> isn't the idea not to use exceptions unless absolutely necessary ?
15:11:56 <Josh_Soref> ... we need to look at which things are synchronous/asynchronous
15:12:08 <Josh_Soref> ... and we could move some things to the DOM document
15:12:20 <Josh_Soref> ... it isn't as simple as what's in hta 's document, and we need another level of analysis
15:12:44 <Josh_Soref> ekr: the technical changes that paul proposes
15:12:48 <Josh_Soref> ... are QQQ
15:12:55 <Josh_Soref> ... the rest i'm happy to defer to WebRTC
15:12:56 <hta> s/QQQ/fine/
15:13:09 <Josh_Soref> s/paul/hta/
15:13:10 <Josh_Soref> s/paul/hta/
15:13:26 <hta> zakim, unmute me
15:13:26 <Zakim> hta should no longer be muted
15:13:27 <Josh_Soref> RRSAgent, draft minutes
15:13:27 <RRSAgent> I have made the request to generate http://www.w3.org/2013/05/07-mediacap-minutes.html Josh_Soref
15:13:31 <gmandyam> Dom, I'm muting on my local phone.  I can ask Zakim to mute me too if you prefer.
15:13:43 <Josh_Soref> hta: ekr, could you take an action to file an WWW with WebRTC
15:14:02 <Josh_Soref> ... that addIceCandidate is missing a failure callback
15:14:05 <dom> Zakim, mute hta
15:14:05 <Zakim> hta should now be muted
15:14:05 <Josh_Soref> ekr: sure
15:14:11 <Josh_Soref> burn: do we need to file bugs for everything?
15:14:16 <dom> Zakim, unmute hta
15:14:16 <Zakim> hta should no longer be muted
15:14:20 <Josh_Soref> ... if we agree to change it, i'm ok
15:14:29 <dom> Zakim, mute hta
15:14:29 <Zakim> hta should now be muted
15:14:31 <Josh_Soref> hta: with the number of bugs we've already forgotten, i want to file a bug
15:14:39 <Josh_Soref> burn: ok
15:14:46 <Josh_Soref> stefanh: ok, for the rest of hta 's proposal
15:14:53 <Josh_Soref> ... i think we're ok with it, but we need more details
15:15:00 <Josh_Soref> s/burn/fluffy/
15:15:03 <Josh_Soref> s/burn/fluffy/
15:15:07 <Zakim> + +33.2.31.26.aagg
15:15:23 <Josh_Soref> gmandyam: things need to be determined individually/accordingly
15:15:27 <Josh_Soref> stefanh: i agree
15:15:33 <hta> zakim, unmute me
15:15:33 <Zakim> hta should no longer be muted
15:15:42 <hta> I'm muting locally......
15:15:46 <Josh_Soref> Topic: Futures
15:16:02 <Josh_Soref> stefanh: can someone from Google, Microsoft or Mozilla introduce
15:16:13 <Josh_Soref> jesup: i did some querying w/ people at Mozilla about the status of Futures
15:16:24 <Josh_Soref> ... it sounds, and i'll go after i stop talking to re-verify the email i got
15:16:34 <Josh_Soref> ... the indication was that it was going to be ready in the relatively near future
15:16:42 <Josh_Soref> ... so it could be ready for us to use it
15:16:47 <Josh_Soref> ... i don't think it's in Firefox 23
15:16:54 <Josh_Soref> ... but i'm guessing it could be in Firefox 24
15:16:58 <gmandyam> Does jquery count as an implementer of Futures?  See http://api.jquery.com/promise/.
15:16:59 <Josh_Soref> ... i'll need to double check my email
15:17:04 <Josh_Soref> ... unless someone else has more details
15:17:08 <Josh_Soref> stefanh: timeframe for 24?
15:17:12 <Josh_Soref> jesup: 6-week cycles
15:17:16 <Josh_Soref> ... 24 goes to alpha in 7 weeks
15:17:18 <dom> gmandyam, that wouldn't help in this case (this needs to be available directly in the browser, since this is a browser API)
15:17:22 <Josh_Soref> ... and beta 6 weeks after that
15:17:25 <Josh_Soref> ... release 6 after that
15:17:33 <dom> s/stefanh:/hta:/
15:17:33 <Josh_Soref> ... so, 24 is in about 18-19 weeks
15:17:51 <Josh_Soref> mreavy: they're planning on having something out by the end of the year
15:17:58 <Josh_Soref> ... but they don't have a release targeted yet
15:18:13 <Josh_Soref> ... but if we have a need, the priority could be bumped up
15:18:18 <Josh_Soref> jesup: that matches with my email
15:18:18 <gmandyam> +q
15:18:26 <Josh_Soref> mreavy: they're looking at end of year, probably 25/26
15:18:33 <Josh_Soref> ... but the priority could be bumped
15:18:42 <Josh_Soref> jesup: i don't know anne is on
15:18:48 <Josh_Soref> ... the review i saw
15:18:53 <Stephane> Stephane has joined #mediacap
15:19:04 <Josh_Soref> ... it sounded like one way could be to compose our API so that it's easily replaced with a Futures implementation
15:19:20 <Josh_Soref> ... looking at takePhoto() and see if it could be converted to Futures in the future
15:19:38 <dom> Zakim, aagg is Stephane
15:19:38 <Zakim> +Stephane; got it
15:19:38 <Josh_Soref> ... and as roc indicated on the list, we could deploy a Futures based version, and support the existing api using that, and not break people
15:19:57 <Josh_Soref> hta: when i asked the question again of Chrome, the date moved
15:20:15 <Josh_Soref> ... end of year sounds like a reasonable guess, but we don't have a commitment
15:20:16 <Josh_Soref> q?
15:20:18 <Josh_Soref> ack gmandyam
15:20:48 <Josh_Soref> gmandyam: mreavy / jesup : in SysApps the Firefox OS guys have agreed to transition to DOM Futures, even though DOM Request is already supported by Gecko
15:21:05 <Josh_Soref> ... but wrt integration of SysApps, are you saying there's no commitment?
15:21:14 <Josh_Soref> jesup: i don't know anything about SysApps in particular
15:21:21 <Josh_Soref> ... i can certainly query the DOM team about what they're planning
15:21:26 <Josh_Soref> ... and re-verify with them
15:21:35 <Josh_Soref> ... it's possible the SysApps people haven't coordinated w/ the DOM team
15:21:42 <Josh_Soref> ... or maybe there's coordination i don't know about
15:21:58 <Josh_Soref> ... i queried a few weeks ago, and that's the information i had
15:22:09 <Josh_Soref> gmandyam: if we decide to go forward w/ specs that are easily transitionable to futures
15:22:14 <Josh_Soref> ... that's not a problem
15:22:28 <Josh_Soref> ... there's another comment that darobin had about DOM Targets
15:22:32 <Josh_Soref> ... and BBB
15:22:42 <Josh_Soref> ... so should we move to a pure callback/event target model
15:22:54 <Josh_Soref> jesup: we should consider moving to one common API structure
15:22:59 <Josh_Soref> ... that's most easily transitionable in the future
15:23:10 <Josh_Soref> s/ Target/EventTarget/
15:23:23 <Josh_Soref> hta: the events and callbacks are used for different purposes
15:23:32 <Josh_Soref> ... the callbacks are very much aligned w/ the model that futures is trying
15:23:39 <Josh_Soref> ... and events are for things futures can't be used for
15:23:50 <Josh_Soref> ... to represent things that happened due to outside influence
15:23:57 <ekr> q+
15:24:00 <Josh_Soref> ... so i don't think it's as troublesome as what darobin indicated
15:24:02 <Josh_Soref> gmandyam: thanks
15:24:04 <Josh_Soref> ack ekr
15:24:26 <Josh_Soref> ekr: i don't object to being open to the idea of converting to Futures at some point in the future
15:24:39 <Josh_Soref> ... this seems to be of minimal benefit
15:24:44 <Josh_Soref> ... minimal actual technical benefit
15:24:46 <dom> q+
15:24:47 <jesup> q+
15:24:53 <Josh_Soref> ack dom
15:25:08 <Josh_Soref> dom: converting to Futures has more than a minimal technical benefit
15:25:17 <ekr> q+
15:25:18 <Josh_Soref> ... it gives properties of chaining and code organization
15:25:26 <Josh_Soref> ... in particular if the rest of the platform is moving to it
15:25:30 <Josh_Soref> ... i think we should align
15:25:39 <Josh_Soref> ... from the content-developer's perspective, it's a pretty big benefit
15:25:40 <Josh_Soref> ack jesup
15:25:47 <Josh_Soref> jesup: +1
15:26:03 <Josh_Soref> ... the DOM team says this is the way they're moving for this sort of async APIs
15:26:04 <Josh_Soref> q?
15:26:07 <Josh_Soref> ack ekr
15:26:25 <Josh_Soref> ekr: i've programmed in every possible Asynchronous programming idiom
15:26:28 <Josh_Soref> ... they're all awful
15:26:38 <Josh_Soref> ... it's possible to polyfill this into anything else
15:26:43 <Josh_Soref> ... get, Twisted and try it
15:26:57 <Josh_Soref> ... once we have 10 years of experience of Futures based experience
15:27:07 <Josh_Soref> ... people will be just as irritated by them as they are by callbacks
15:27:28 <Josh_Soref> stefanh: we had a discussion before this meeting, hta, I, and dom
15:27:38 <ekr> I am happy to defer this discussion
15:27:38 <Josh_Soref> ... i think we should have a separate meeting just to discuss this
15:27:45 <jesup> q+
15:27:47 <Josh_Soref> ... there are reasons we could move, or reasons we shouldn't
15:27:53 <Josh_Soref> ... i don't know if that sounds reasonable
15:27:54 <Josh_Soref> ack jesup
15:28:04 <fluffy> ?+
15:28:06 <fluffy> ?
15:28:11 <fluffy> q+
15:28:14 <fluffy> q?
15:28:15 <Josh_Soref> hta: not if we should move, but when we should move
15:28:29 <Josh_Soref> jesup: i agree, if we want to have a separate meeting, i can try to rope in the other DOM people for that call
15:28:34 <Josh_Soref> ack fluffy
15:28:48 <Josh_Soref> fluffy: can we make sure we get in the minutes that the major browser vendors
15:28:53 <Josh_Soref> ... were thinking of having it sometime this year
15:28:56 <Josh_Soref> ... but not a specific time
15:29:15 <Josh_Soref> burn: i was watching the minutes, and i saw them go by for Firefox and Chrome
15:29:21 <jesup> do we know what IE will support them?  Or Safari?
15:29:27 <jesup> s/what/when/
15:29:28 <Josh_Soref> hta: for APIs we don't have impls, like Image Capture
15:29:33 <Josh_Soref> ... we could spec using Futures
15:29:35 <dom> s/hta:/stefanh:/
15:30:05 <Josh_Soref> topic: “Media Capture and Streams” document
15:30:11 <dom> -> http://lists.w3.org/Archives/Public/public-media-capture/2013May/att-0016/mediacap20130507Burnett.pdf Dan's slides
15:30:13 <Josh_Soref> burn: i sent a few slides to the list
15:30:21 <Josh_Soref> ... ~two hours ago
15:30:24 <Josh_Soref> ... not much in them
15:30:28 <Josh_Soref> ... a draft came out last week
15:30:35 <Josh_Soref> ... i'm not going to review all the changes in the draft
15:30:42 <Josh_Soref> ... i'll briefly state the major changes
15:30:51 <Josh_Soref> ... i added States and Capabilities as we discussed at the Interim
15:30:56 <Josh_Soref> ... i had to adjust the syntax slightly
15:31:04 <Josh_Soref> ... this method syntax is the same as for Constraints
15:31:20 <Josh_Soref> ... getConstraints() ~ getStates() ~ getCapabilities()
15:31:28 <Josh_Soref> ... adam made a number of updates for MediaStream Tracks
15:31:32 <Josh_Soref> ... for lifecycle and cloning
15:31:39 <Josh_Soref> ... it applies to cloning not just track
15:31:47 <Josh_Soref> ... adam also updated FFF
15:31:58 <ekr> Looking at this, should applyConstraints be asynchronous?
15:31:59 <Josh_Soref> ... and removed Capture since there's a separate document for it
15:32:03 <Josh_Soref> ... getUserMedia is now mandatory
15:32:12 <Josh_Soref> [ next slide ]
15:32:16 <Josh_Soref> burn: i listed Non-hanges
15:32:19 <Josh_Soref> s/hang/chang/
15:32:24 <Josh_Soref> ... things we decided not to do
15:32:35 <Josh_Soref> ... Travis had pictures of things that happen
15:32:46 <Josh_Soref> ... i didn't have time to include an update to his pictures + text
15:33:07 <Josh_Soref> s/slide ]/slide: Non-changes]/
15:33:28 <Josh_Soref> [ Slide: Constraint/state/capability discussion items ]
15:33:38 <Josh_Soref> burn: there was a question about how tied together they were
15:33:42 <Josh_Soref> ... needs more thought
15:33:57 <Josh_Soref> [ Slide: MediaStreamTrack discussion items ]
15:34:11 <Josh_Soref> burn: constraint date capability
15:34:15 <Josh_Soref> ... not media-flow
15:34:22 <Josh_Soref> ... there were emails from hta and gmandyam
15:34:31 <Josh_Soref> ... i gave brief replies just before this meeting
15:34:40 <Josh_Soref> ... points to discuss, not in any particular order
15:34:44 <Josh_Soref> s//[ Slide: MediaStreamTrack discussion items ]/
15:34:52 <Josh_Soref> ... hta pointed out there are 4 constraint types
15:35:09 <Josh_Soref> ... Min/max, Enum, (int/float/etc), unconstrained string
15:35:19 <Josh_Soref> ... - int/float are actually
15:35:33 <Josh_Soref> ... -- when you set a specific value, that's syntactic sugar for setting Min == Max
15:35:49 <Josh_Soref> ... we discussed this at the meeting and agreed to allow this
15:35:57 <Josh_Soref> ... re: unconstrained string, a primitive type
15:36:03 <Josh_Soref> ... i felt we needed to leave it in
15:36:06 <Josh_Soref> ... because of `sourceId`
15:36:18 <Josh_Soref> ... it doesn't fit as an Enum or a Min/Max
15:36:26 <Josh_Soref> ... i tried to avoid them
15:36:39 <Josh_Soref> ... i was afraid once you allowed unconstrained, everything would be
15:36:55 <Josh_Soref> ... another to consider is aspectRatio
15:37:02 <Josh_Soref> ... anytime i've shown any example of 4:3
15:37:13 <Josh_Soref> ... as 1.33-something, i here complaints that it isn't correct and we MUST not do that
15:37:18 <Josh_Soref> ... so we need a way to represent 4:3
15:37:28 <Josh_Soref> ... a string, or maybe it's possible as an Enum type
15:37:45 <Josh_Soref> hta: i wasn't trying to make objection to anything
15:37:53 <Josh_Soref> ... unconstrained things are needed to represent identifiers
15:38:08 <Josh_Soref> ... i wanted to make sure we realized the changes we're making
15:38:19 <Josh_Soref> ... wrt. Min/Max, i think we need to say Min is evaluated before Max or vice-versa
15:38:26 <Josh_Soref> ... we need to agree to do it a single way
15:38:28 <Josh_Soref> burn: ok
15:38:44 <Josh_Soref> ... if setting a value = set min+set max, we need to specify order of evaluation
15:38:47 <Josh_Soref> ... for prioritization
15:38:49 <Josh_Soref> hta: exactly
15:38:54 <Josh_Soref> burn: no problem w/ that
15:39:07 <Josh_Soref> ... barring other detailed suggestion, i'd probably say `min; and then max`
15:39:11 <Josh_Soref> ... because i don't really care
15:39:24 <ekr> q+
15:39:28 <Josh_Soref> ack ekr
15:39:31 <ekr> Sorry I decided to be a good guy
15:39:44 <Josh_Soref> s/Sorry I decided to be a good guy//
15:39:52 <Josh_Soref> ekr: i agree these types are fine
15:39:59 <Josh_Soref> ... i agree w/ the general principle to avoid using strings
15:40:07 <Josh_Soref> ... i admire burn 's attempt to avoid that
15:40:12 <Josh_Soref> ... i believe it will be a failed attempt
15:40:18 <Josh_Soref> ... but i'm happy to continue with it
15:40:21 <Josh_Soref> burn: thanks for that
15:40:27 <Josh_Soref> ... i think sourceId is where it fails
15:40:29 <fluffy> q+
15:40:38 <Josh_Soref> ... from Travis's proposal
15:40:43 <Josh_Soref> ... i'll leave it for sourceIds for now
15:40:55 <Josh_Soref> ... and try to hold the line/argue strongly against it eveyone else
15:41:06 <Josh_Soref> ... hta may be right that identifiers will be where we don't have a choice
15:41:16 <Josh_Soref> fluffy: why not use integers for sourceIds
15:41:24 <Josh_Soref> burn: today we have no constraints on what a sourceId
15:41:31 <Josh_Soref> fluffy: we have no requirement on that either
15:41:37 <Josh_Soref> ... if this helps you hold the line, i don't care
15:41:42 <Josh_Soref> burn: can you propose that to the list
15:41:46 <Josh_Soref> ... if no one objects, then it's fine
15:41:48 <ekr> burn: what areas are you soliciting comments on at this time?
15:41:54 <Josh_Soref> ... if we get an objection, we have a discussion on the list
15:41:57 <ekr> I.e., the entire spec? Just this one point?
15:42:07 <ekr> sounds good
15:42:21 <Josh_Soref> burn: constraints, then gmandyam 's question, then other, then MediaStreamTrack
15:42:24 <jesup> I see no problem with unconstrained integers for source id's
15:42:34 <Josh_Soref> ... gmandyam had a question, it had come up before
15:42:41 <Josh_Soref> ... i'm nervous about bringing this up
15:43:09 <Josh_Soref> ... "A source's state must always conform to the current set of	 mandatory constraints ..."
15:43:13 <Josh_Soref> ... that needs to be reworded
15:43:34 <Josh_Soref> ... to say that Tracks are over-constrained if at any point their mandatory constraints don't match their states
15:43:41 <Josh_Soref> ... but gmandyam 's question would still apply
15:43:48 <Josh_Soref> ... say you have a source, that sets a value "Q"
15:43:55 <Josh_Soref> ... to "10"
15:44:01 <Josh_Soref> ... and the tracks associated with it
15:44:12 <Josh_Soref> ... have set a mandatory constraint of ">=30"
15:44:21 <Josh_Soref> ... why is it that that forces an overconstrained case
15:44:31 <Josh_Soref> ... if the browser or middleware could do a mapping from 10 to 30
15:44:40 <Josh_Soref> ... scaling video, scaling volume on audio, ...
15:44:58 <Josh_Soref> ... what does it mean for a track to be overconstrained relative to the source
15:45:08 <Josh_Soref> ... and can processing between source and track handle this
15:45:17 <Josh_Soref> ... it brought up a 3 hour discussion at the meeting
15:45:22 <Josh_Soref> gmandyam: that covers the item
15:45:27 <Josh_Soref> ... i gave a 10fps to a 30fps example
15:45:33 <fluffy> q+
15:45:39 <Josh_Soref> ... i don't want to open the issue, but i want a resolution
15:46:03 <Josh_Soref> ... something to say `things must be done by the source with no additional processing`
15:46:25 <Josh_Soref> ... part of the contract in WebRTC is that the stream will be returned in a quick fashion
15:46:34 <Josh_Soref> ... i'm not advocating one way or the other
15:46:35 <burn> q+
15:46:35 <Josh_Soref> ack fluffy
15:46:43 <jesup> q+
15:46:46 <Josh_Soref> fluffy: i think the spec should say processing is ok
15:46:49 <Josh_Soref> ... but you can't create fake data
15:46:51 <stefanh> +1 to Cullen
15:46:58 <ekr> q_
15:46:59 <ekr> q+
15:46:59 <Josh_Soref> ... if i ask for 30fps and you have
15:47:03 <Josh_Soref> ... i don't want that
15:47:11 <Josh_Soref> ... i understand it's hard to implement on the mac
15:47:18 <Josh_Soref> burn: that's a stronger statement than i would make
15:47:28 <Josh_Soref> q+ to note that fake data at request of user should be allowed
15:47:36 <Josh_Soref> burn: what i need as a developer
15:47:41 <Josh_Soref> ... if i say minimum of 30
15:47:46 <Josh_Soref> ... and i get the "media"
15:47:50 <Josh_Soref> ... and there's no error
15:47:55 <Josh_Soref> ... and i check the setting on the source
15:48:01 <Josh_Soref> ... then the value better be "30 or greater"
15:48:05 <Josh_Soref> ... who defines what a source is
15:48:09 <Josh_Soref> ... ultimately, it's the Browser
15:48:17 <Josh_Soref> ... it's the agent for the user, and actually the agent for the developer
15:48:26 <Josh_Soref> ... i can't stop the browser from doing processing on what it gets from the device
15:48:33 <Josh_Soref> ... it has to give me a value i can work with
15:48:39 <Josh_Soref> ... if it says "30 was satisfied"
15:48:48 <Josh_Soref> ... then i can expect to see a 30 (or better) as a setting
15:48:55 <Josh_Soref> ack burn
15:48:58 <Josh_Soref> ack dan
15:49:00 <Josh_Soref> ack jesup
15:49:05 <Josh_Soref> jesup: pretty much agree w/ burn
15:49:09 <Josh_Soref> ... as to the fake data issue
15:49:10 <Jim_> Zakim, Q+
15:49:10 <Zakim> I see ekr, Josh_Soref, Jim_ on the speaker queue
15:49:14 <Josh_Soref> ... i understand what fluffy is saying
15:49:26 <Josh_Soref> ... but that might not be under the control of the browser
15:49:30 <Josh_Soref> ... for scaling, is that fake data
15:49:35 <Josh_Soref> ... it's derived data
15:49:41 <Josh_Soref> ... it's interpollated
15:49:54 <Josh_Soref> ... what if 10fps to 30fps is interpolated by the camera
15:50:07 <Josh_Soref> ... some of these settings yield derived data
15:50:07 <Travis> Travis has joined #mediacap
15:50:15 <Josh_Soref> ... i don't know it's hard to say
15:50:16 <fluffy> q?
15:50:27 <Josh_Soref> ... the browser may wish to provide fake data in place of real data
15:50:32 <Josh_Soref> ... on purpose, perhaps at the user's request
15:50:34 <Josh_Soref> Josh_Soref: +1
15:50:36 <Josh_Soref> q- Josh_Soref
15:50:47 <Josh_Soref> ... the browser is trying to respond to the user's requests here
15:51:06 <Josh_Soref> ... and trying to find a way to integrate what's provided by the OS/hardware to the requirements put upon it
15:51:11 <Josh_Soref> ... up to the browser to try to satisfy
15:51:14 <Josh_Soref> ... if it can, it succeeds
15:51:22 <Josh_Soref> ... if it can't, it fails, and is overconstrained
15:51:24 <Josh_Soref> ack ekr
15:51:35 <fluffy> q+
15:51:37 <Josh_Soref> ekr: i'd like to hear fluffy clarify "fake data"
15:51:41 <Josh_Soref> ... take the fps case
15:51:44 <Josh_Soref> ... you ask for 30fps
15:51:46 <Josh_Soref> ... and i have 10fps
15:51:53 <Josh_Soref> ... can i replicate the frame 3 times
15:51:57 <Josh_Soref> ... or do you want an error?
15:52:11 <Josh_Soref> ... is it ok for the browser under user control to synthesize bogus data
15:52:14 <Zakim> +[Microsoft]
15:52:22 <Josh_Soref> ... different question
15:52:28 <Josh_Soref> ... user could point Camera at TV
15:52:33 <Travis> Zakim, Microsoft is me
15:52:33 <Zakim> +Travis; got it
15:52:36 <Josh_Soref> ... fluffy 's point blurs the details
15:52:41 <Travis> Present+ Travis_Leithead
15:52:43 <Josh_Soref> ... i'd rather know if i get what i expected to get
15:52:49 <Josh_Soref> ... than have the browser help me out
15:53:00 <Josh_Soref> fluffy: agree w/ creating synthetic data/data spooled from disk
15:53:06 <Josh_Soref> ... we have Optional and Mandatory
15:53:12 <Josh_Soref> ... if i put Optional, i'm ok w/ it doing this
15:53:21 <Josh_Soref> ... if i put 30fps Mandatory, i want an error
15:53:29 <Josh_Soref> ... the issue i'm really concerned about
15:53:33 <Josh_Soref> ... isn't fps,
15:53:36 <Josh_Soref> ... if i ask for 4k video
15:53:45 <Josh_Soref> ... a device on mobile has a simple video
15:53:52 <Josh_Soref> ... if you allow for upscaling
15:53:55 <jesup> q+
15:54:01 <Josh_Soref> ... people will resort to UA sniffing
15:54:04 <Josh_Soref> ... so, no fake data
15:54:14 <Josh_Soref> burn: i'm at the end of my slides
15:54:23 <ekr> q+
15:54:24 <Josh_Soref> ... any discussion on MC can happen at this point
15:54:34 <Josh_Soref> stefanh: we're running out of time
15:54:37 <Josh_Soref> ack Jim_
15:54:37 <fluffy> q-
15:54:55 <Josh_Soref> Jim_: to gmandyam 's point, that he's alright with him if constraints were pushed back to the source
15:55:09 <Josh_Soref> ... don't they have to have processing in tracks if there are tracks with different values
15:55:15 <Josh_Soref> gmandyam: yeah basically
15:55:37 <Josh_Soref> ... i gave feedback on cloning/multiple tracks from the same source
15:55:42 <Josh_Soref> ... i think it's interesting
15:55:47 <Josh_Soref> ... but will complicate things
15:55:56 <Josh_Soref> ... i think track-per-source is enough for what we need in a first version
15:56:05 <Josh_Soref> ... i realize there are more complicated UCs in the UC doc
15:56:07 <Josh_Soref> Jim_: ok
15:56:09 <Josh_Soref> ack jesup
15:56:17 <Josh_Soref> jesup: to fluffy, i understand his concern there
15:56:24 <Josh_Soref> ... we don't want people to move to UA sniffing/etc
15:56:36 <Josh_Soref> ... there's a difference between Mandatory and Optional
15:56:43 <Josh_Soref> ... Mandatory should be used in very specific cases
15:56:54 <Josh_Soref> ... in most cases, apps shouldn't be using Mandatory constraints in the first case
15:57:04 <Josh_Soref> ... if it's a true mandatory constraint, perhaps we deal w/ that differently
15:57:12 <Josh_Soref> ... in terms of allowing upsampling
15:57:16 <Josh_Soref> ... than for optional
15:57:21 <burn> burn has joined #mediacap
15:57:22 <Josh_Soref> ... i'm willing to consider a change for that
15:57:29 <Josh_Soref> ... the alternative would be another mandatory constraint
15:57:37 <Josh_Soref> ... "no Interpolation"
15:57:49 <Josh_Soref> ... i want this, and you aren't allowed to adjust things
15:57:53 <Josh_Soref> ... meet-or-fail
15:58:06 <Josh_Soref> ... those are the two options to solve fluffy 's problem
15:58:07 <Josh_Soref> ack ekr
15:58:14 <Josh_Soref> ekr: i'm ok w/ fluffy 's view of the universe
15:58:23 <Josh_Soref> ... i'd assume that if i asked for optional 30
15:58:25 <Josh_Soref> ... and you had 10
15:58:33 <Josh_Soref> ... you'd give me 10 and not interpolate to 30fps
15:58:43 <Josh_Soref> ... the one difficulty here
15:58:54 <Josh_Soref> ... is we'd need an entirely different api to allow people to do such things
15:59:01 <Josh_Soref> ... but we'd have to create such infrastructure
15:59:06 <fluffy> q+
15:59:12 <Josh_Soref> burn: i agree this is about Mandatory and not Optional
15:59:18 <ekr> q+ (for a different topic)
15:59:23 <ekr> q+
15:59:24 <Josh_Soref> ... for "i want this and only this"
15:59:25 <ekr> (different topic)
15:59:28 <Josh_Soref> ... it's a mandatory situation
15:59:39 <fluffy> q-
15:59:42 <Josh_Soref> stefanh: this discussion could continue longer, but we're out of time on this topic
15:59:57 <Josh_Soref> Topic: Close CfC to publish this version
16:00:04 <Josh_Soref> stefanh: the CfC ...
16:00:10 <Josh_Soref> ... i saw no objection to publish
16:00:14 <Josh_Soref> ... gmandyam had requests for changes
16:00:28 <Josh_Soref> gmandyam: i had the request to get rid of the photo camera source before publishing
16:00:33 <Josh_Soref> ... but if Jim_ could do that
16:00:40 <Josh_Soref> burn: i can change that
16:00:43 <Josh_Soref> ... it's a pretty easy change
16:01:09 <Josh_Soref> stefanh: we'll discuss TPAC on list
16:01:19 <Josh_Soref> topic: Introducing what we need to do to go to LCWD, and what to expect
16:01:33 <Jim_> q+
16:01:38 <ekr> q+
16:01:42 <Josh_Soref> dom: we are striving to push MC and Streams to LC in the upcoming couple of months
16:01:53 <dom> http://lists.w3.org/Archives/Public/public-media-capture/2013May/0021.html
16:01:53 <Josh_Soref> ... the chairs asked me to clarify to the group what it meant to go to LC
16:02:10 <Josh_Soref> ... LC means the WG or WGs (as we're a TF)
16:02:25 <Josh_Soref> ... feel that the spec fulfills their requirements
16:02:31 <Josh_Soref> ... and no known-issues are open to the spec
16:02:41 <Josh_Soref> ... it's a signal to the World that the spec is done at a technical level
16:02:50 <Josh_Soref> ... and that the WG(s) are seeking external feedback
16:03:01 <Josh_Soref> ... before that, we need consensus from the group that we're ready
16:03:10 <Josh_Soref> ... to achieve LC in a reasonable timeframe
16:03:23 <Josh_Soref> ... the TF members should make sure their issues are raised
16:03:33 <burn> I have to drop off now.  I understand Last Call needs.  My opinion is that we have a number of important issues remaining, not least of which is identifying official list of constraints to register.  Bye.
16:03:34 <Josh_Soref> ... and get feedback from their entities to make sure their requirements are met
16:03:47 <Zakim> -Dan_Burnett
16:03:58 <Josh_Soref> ... make sure to raise your issues, sooner, rather than later
16:04:00 <ekr> burn++
16:04:15 <Josh_Soref> ... once we go to LC, we need to identify groups inside and outside from which we want feedback
16:04:31 <Josh_Soref> ... i listed: * Web Apps WG * Audio WG * Privacy Interest Group * Web & TV Interest Group
16:04:35 <Josh_Soref> ... also HTML would make sense
16:04:44 <Josh_Soref> ... i listed ECMA TC39 - they're developing JS
16:04:56 <Josh_Soref> ... and they're offering to review JS APIs to make sure they feel like JS APIs
16:05:12 <Josh_Soref> ... and i listed IETF RTCWeb WG given they're strongly linked w/ WebRTC
16:05:19 <Josh_Soref> ... once we've decided this, we go to LC
16:05:24 <Josh_Soref> ... we set a duration for the LC period
16:05:29 <Josh_Soref> ... at least 3 weeks, possibly more
16:05:34 <Josh_Soref> ... especially if we do it during Summer
16:05:40 <Josh_Soref> ... to make sure people have time to do their reviews
16:05:48 <Josh_Soref> ... during the LC period, we'll receive any number of comments
16:05:58 <Josh_Soref> ... both from groups we've identified and from people outside those groups
16:06:04 <Josh_Soref> ... each comment needs to be formally processed
16:06:08 <Josh_Soref> ... we need to respond to them
16:06:21 <Josh_Soref> ... and get feedback from commenter to see if they agree we've addressed their comment
16:06:33 <Josh_Soref> ... if they disagree, we'd need to collect a formal objection from them
16:06:47 <Josh_Soref> ... formal objections need to be taken to the Director before we go to the next step
16:06:48 <Zakim> -fluffy
16:06:58 <Josh_Soref> ... once we've gathered the feedback and integrated the changes
16:07:03 <Josh_Soref> ... we can either go back to LC
16:07:14 <Josh_Soref> ... or we could go to CR if there were no substantive changes
16:07:23 <Josh_Soref> ... at CR, the focus is gathering feedback based on testing
16:07:33 <Josh_Soref> ... i think that's a fair summary of this whole process
16:07:37 <Josh_Soref> ... Questions / Remarks ?
16:08:03 <Josh_Soref> stefanh: dom, based on your experience, when should we move to LC?
16:08:10 <Josh_Soref> dom: you make me feel old
16:08:38 <Josh_Soref> ... it feels like people are waiting until meetings to raise issues. we only have limited visibility on how far along we are
16:08:52 <Josh_Soref> ... the duration is proportional to the time people spend reviewing/making proposals
16:09:08 <Josh_Soref> ... if the group(s) as a whole dedicate their next 2-3 weeks reviewing/making proposals
16:09:12 <Josh_Soref> ... then we can go to LC next month
16:09:23 <Josh_Soref> ... if people wait for 4 weeks, then that delays LC for another month at least
16:09:34 <Josh_Soref> ... i don't think there's a better rule than that, really
16:09:38 <ekr> q?
16:09:43 <Josh_Soref> ack Jim_
16:09:58 <Josh_Soref> Jim_: from experience w/ another spec, writing tests catches lots of bugs in the spec
16:10:07 <Josh_Soref> ... one question is how many times do we want to go to LC
16:10:13 <Josh_Soref> ... if we only want to do it once
16:10:20 <Josh_Soref> ... then we need to work on tests
16:10:22 <Josh_Soref> dom: yes
16:10:27 <Josh_Soref> ... i started writing tests a year ago
16:10:31 <Josh_Soref> ... i need to update them
16:10:37 <Josh_Soref> ... there's a risk of catch-22
16:10:44 <Josh_Soref> ... if we don't update/do update
16:10:52 <Josh_Soref> ... we did a first pass of reviews through testing last year
16:10:59 <ekr> q?
16:11:01 <Josh_Soref> ... i agree another round of that would be a useful exercise before LC
16:11:07 <Josh_Soref> ... i'm willing to take an action item to do that
16:11:08 <Josh_Soref> ack ekr
16:11:14 <Josh_Soref> ekr: re: tests
16:11:22 <Josh_Soref> ... i don't have an intelligent opinion on how close to LC
16:11:29 <Josh_Soref> ... no one has implemented half this stuff
16:11:35 <Josh_Soref> ... i think we're pretty far away
16:11:36 <jesup> ekr++
16:11:42 <Josh_Soref> ... i'd want to see this all implemented
16:11:45 <Josh_Soref> ... issues mostly closed
16:11:52 <Josh_Soref> ... and see something built with it
16:12:01 <Josh_Soref> ... i think we're pretty far away
16:12:04 <Josh_Soref> dom: i hear you
16:12:14 <Josh_Soref> ... we've been saying we've been pretty far away for 8 months now
16:12:24 <Josh_Soref> ... w/o a focal point, we'll always be pretty far away
16:12:28 <fluffy> FWIW, I don't think this is close to ready yet
16:12:30 <Josh_Soref> ... if part of the spec isn't implemented
16:12:40 <Josh_Soref> ... then perhaps we can go to LC w/ the half that is implemented
16:12:46 <Josh_Soref> ... people are starting to use this api
16:12:51 <Josh_Soref> ... if we don't get something interoperable soon
16:12:56 <Josh_Soref> ... we're pushing costs to developers
16:13:05 <Josh_Soref> ... and implementers when they need to push breaking changes
16:13:12 <mreavy> fluffy++, ekr++
16:13:16 <Josh_Soref> ... i think we need to have a reasonable idea on how to get visibility
16:13:33 <Josh_Soref> stefanh: i agree we have to pick a date
16:13:39 <Josh_Soref> ... otherwise it'll always be far away
16:13:47 <Josh_Soref> topic: “Image Capture” document
16:14:01 <Josh_Soref> gmandyam: i sent a slide deck this morning
16:14:09 <Josh_Soref> ... there's a typo as dom pointed out
16:14:29 <stefanh> giri's slides: http://lists.w3.org/Archives/Public/public-media-capture/2013May/att-0017/Image_Capture_spec_changes_May_2013.pdf
16:14:33 <jesup> dom has a point, but I think we need more implementation to get to last call - perhaps choose a date based on projected "most of" the api implemented
16:14:39 <Josh_Soref> ... i got rid of frameGrabber() based on feedback
16:14:52 <Josh_Soref> ... based on comment from roc, i made whitebalance closer to temperature
16:14:58 <Josh_Soref> ... i think fluffy pointed this out months ago
16:15:17 <Josh_Soref> ... i trust people to give me feedback on the list
16:15:27 <Josh_Soref> [ Slide: Existing issues specific to ImageCapture ]
16:15:32 <Josh_Soref> gmandyam: making the stream track simpler
16:15:35 <Josh_Soref> ... with a sourcetype
16:15:39 <Josh_Soref> ... i think we're having that
16:15:44 <Josh_Soref> ... the Zoom constraint
16:15:55 <Josh_Soref> ... my preference is for camera preview streams
16:16:02 <Josh_Soref> ... that the stream be created w/ the zoom constraint
16:16:08 <Josh_Soref> ... rather than applying w/ photo
16:16:17 <Josh_Soref> ... i want correspondence with the capture device
16:16:23 <Josh_Soref> ... if zoom isn't present, there's CSS transforms
16:16:45 <Josh_Soref> ... but in doing that, you don't know if the zoom shown to the user is the same as in the capture device
16:16:57 <Josh_Soref> ... Jim_ said aspect ratio is high priority, but zoom isn't
16:17:11 <jesup> q+
16:17:12 <Josh_Soref> [ Slide: Broader Issues ]
16:17:22 <Josh_Soref> gmandyam: i'm not going to adjust to use DOM Futures
16:17:29 <Josh_Soref> ... i think we can do DOM Futures in a later version
16:17:39 <Josh_Soref> ... on DOM Errors, we have a resolution from hta to transition there
16:17:44 <Josh_Soref> ... i'll go through the spec
16:17:51 <Josh_Soref> ... i think right now everything makes sense as Errors
16:18:03 <Josh_Soref> ... i think i'm running out of things to tweak
16:18:11 <Josh_Soref> ... looking for guidance on what to do next
16:18:13 <Josh_Soref> ack jesup
16:18:18 <Josh_Soref> jesup: the zoom issue
16:18:19 <stefanh> q+
16:18:33 <Josh_Soref> ... while zoom as a create time constraint is less interesting
16:18:46 <Josh_Soref> ... zoom as the ability to change zoom on a track is important on a bunch of UCs
16:18:51 <Josh_Soref> ... and i'm sure fluffy would agree
16:19:01 <Josh_Soref> ... having real support for zoom should be something looking at making the cut
16:19:06 <Josh_Soref> gmandyam: +1
16:19:31 <Josh_Soref> s/Jim_/burn/
16:19:40 <Josh_Soref> stefanh: burn dropped off the call
16:19:49 <Jim_> q+
16:19:58 <Josh_Soref> gmandyam: UUU commented about zoom
16:20:02 <Josh_Soref> ... maybe can +1 on the list
16:20:09 <ekr> cullen dropped off
16:20:10 <derf> q+
16:20:33 <Josh_Soref> jesup: PPP
16:21:00 <Josh_Soref> gmandyam: on Futures, i want to keep the paradigms consistent w/ Recording
16:21:08 <Josh_Soref> Jim_: you know you're going to get a photograph
16:21:18 <stefanh> ack me
16:21:21 <Josh_Soref> ... unlike recording, where you're going to get a series of async devices
16:21:25 <Josh_Soref> ack Jim_
16:21:37 <Josh_Soref> gmandyam: i spoke w/ our implementation guys
16:21:44 <Josh_Soref> ... who worked on Android
16:21:53 <Josh_Soref> ... you can often have multiple pictures
16:21:58 <Josh_Soref> ... you could also get an error back
16:22:05 <Josh_Soref> Jim_: sounds like this needs more discussion
16:22:15 <Josh_Soref> ... whether they fit takePhoto()/Recording
16:22:18 <hta> q+
16:22:20 <Josh_Soref> ack derf
16:22:30 <Josh_Soref> derf: on Zoom, are we talking about controlling Camera lens zoom
16:22:36 <Josh_Soref> ... or cropping/scaling on the image?
16:22:43 <Josh_Soref> gmandyam: i was assuming on the physical camera
16:22:48 <Josh_Soref> derf: thanks
16:22:51 <Josh_Soref> ack hta
16:23:00 <jesup> I assumed the same as gmandyam
16:23:06 <Josh_Soref> hta: my take from anne was that Futures were good
16:23:14 <Josh_Soref> ... when you expect to get either Success or Failure
16:23:18 <Josh_Soref> ... but not Both
16:23:26 <Josh_Soref> ... if you fit that paradigm, futures work
16:23:29 <Josh_Soref> ... if not, then
16:23:44 <Josh_Soref> ... for photo, then that may fit
16:23:49 <Josh_Soref> Jim_: what about Recording
16:23:55 <Josh_Soref> ... where you record to done
16:23:59 <Josh_Soref> ... or you get buffers
16:24:02 <Josh_Soref> ... does that fit or not?
16:24:05 <Josh_Soref> hta: that doesn't fit
16:24:14 <Josh_Soref> Jim_: then we wouldn't want to use Futures
16:24:25 <Josh_Soref> ... i think record-to-done and buffers should follow a single model
16:24:29 <Josh_Soref> ... simpler for developers
16:25:00 <Josh_Soref> stefanh: what is the next step/how far away are we from FPWD
16:25:17 <Josh_Soref> gmandyam: i have minor changes, converting to DOM Errors
16:25:20 <Josh_Soref> ... and a typo
16:25:25 <Josh_Soref> ... then we can go to FPWD
16:25:36 <Josh_Soref> hta: up to FPWD and then let it sit until we have implementers
16:25:38 <dom> +1 to hta
16:25:38 <Josh_Soref> gmandyam: yep
16:25:52 <Josh_Soref> stefanh: ok, time to do that, and then we have a CfC for FPWD
16:25:53 <Josh_Soref> gmandyam: ok
16:26:04 <Josh_Soref> dom: i think that's good
16:26:23 <Josh_Soref> Topic: AOB
16:26:43 <Josh_Soref> gmandyam: MediaStream Tracks and Cloning
16:27:02 <Josh_Soref> stefanh: want more feedback before deciding
16:27:07 <Josh_Soref> jesup: i'd agree w/ that
16:27:11 <Josh_Soref> ... roc responded to hta
16:27:22 <Josh_Soref> ... we thought about Track sharing when it was proposed, and we think it's ok w/ us
16:27:29 <Josh_Soref> stefanh: i don't know if Travis is on the call
16:27:38 <Josh_Soref> Travis: feedback for cloning of tracks
16:27:52 <Josh_Soref> stefanh: having the same track from several streams
16:27:56 <Josh_Soref> ... looking for feedback
16:28:05 <Josh_Soref> Travis: i think an implementer starting today, it wouldn't be a problem
16:28:12 <Josh_Soref> ... i understand there are existing implementations
16:28:22 <Josh_Soref> ... i don't want to lock based on existing implementations
16:28:30 <Josh_Soref> ... i don't think MS feedback would influence this
16:28:44 <Josh_Soref> stefanh: anything else?
16:28:52 <Josh_Soref> ... thanks everyone for joining us
16:28:55 <Josh_Soref> ... thanks to Josh_Soref for scribing
16:28:59 <Josh_Soref> trackbot, end meeting
16:28:59 <trackbot> Zakim, list attendees
16:28:59 <Zakim> As of this point the attendees have been +1.408.902.aaaa, +1.858.651.aabb, gmandyam, Dan_Burnett, +46.1.07.14.aacc, stefanh, fluffy, Josh_Soref, hta, adam, Jim_Barnett, dom,
16:29:02 <Zakim> ... +44.190.881.aadd, +1.650.678.aaee, [Mozilla], +1.610.889.aaff, fjh, +33.2.31.26.aagg, Stephane, Travis
16:29:02 <Zakim> -fjh
16:29:05 <Zakim> -gmandyam
16:29:05 <Zakim> - +1.650.678.aaee
16:29:05 <Zakim> -dom
16:29:05 <Zakim> - +44.190.881.aadd
16:29:07 <trackbot> RRSAgent, please draft minutes
16:29:07 <RRSAgent> I have made the request to generate http://www.w3.org/2013/05/07-mediacap-minutes.html trackbot
16:29:07 <Zakim> - +1.610.889.aaff
16:29:08 <trackbot> RRSAgent, bye
16:29:08 <RRSAgent> I see no action items
16:29:09 <Zakim> -[Mozilla]
16:29:09 <Zakim> -Travis
16:29:10 <Zakim> -Jim_Barnett
16:29:10 <Zakim> -stefanh