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