See also: IRC log
<trackbot> Date: 10 January 2013
<stefanh> Agenda, and some stuff: http://www.w3.org/2011/04/webrtc/wiki/Teleconferences#Thu.2C_Jan_10_2013
<dan_romascanu> aaff may be me
<adambe> Zakim: aaii is me
<fluffy> Zkaim, aaaa is fluffy
<fluffy> thanks dom
<dom> ScribeNick: adambe
stefanh: let's get started
<stefanh> http://www.w3.org/2011/04/webrtc/wiki/Teleconferences#Thu.2C_Jan_10_2013
stefanh: I've pasted the link to
the agenda
... any comments/objections to the agenda
stefanh: we need to aprove the
minutes
... any objections?
<stefanh> minutes: http://lists.w3.org/Archives/Public/public-webrtc/2012Dec/0048.html
stefanh: I consider the minutes
approved
... we're ending the technical session at the hour
stefanh: and discuss how we use the f2f time in February
hta: I'm assuming that everyone has read the proposal
<dom> Stats API proposal
hta: the most important part is
that we've changed the returned report
... away from the local - report format
... into a rtc stats object
... with operators
... the second part is documentation format
... we use WebIDL dictionaries to describe what the data
objects are
... the third part is a few suggestions for stat objects
... that would be part of an actual implementation
... I hope for this meeting that we can get agreement that the
approach is right enough
... and that we can get it into the spec
<JeromeMarcon> +33.6.85.56.aamm = Jerome Marcon
hta: we can work out the the
details as we move on
... that was the intro.. questions?
jesup: in general I don't have a
problem with the design
... how much data could be associated with these objects?
... there might be cases where you want hight detail.. it could
be a lot of data
... we need to make sure people understand that stats could
generate a lot of data
hta: we will end up with quite a
few objects
... defaul will be grab em all
... probably in the 10s of kb range
jesup: we have the space issue.. may not be that big
<adam> ?
jesup: grabing a lot of data that you don't need can hurt you
hta: yes
... I'm been thinking of this in 10s of seconds basis
... if ppl want to do this 100 times a second we're in
trouble
jesup: I'm worried about the size of deep copy operatios
fluffy: I think this is an issue
in selecting stats
... I have a nit with the timestamp
... otherwise, I like it
juberti: I like this too
<jesup> cullen++
juberti: the question is how we
select stats
... We could have an option to say "just give me ICE
stats"
... transport info
... maybe we need a more general way to express what we want to
collect stats about
hta: the selector object started
of as an any type
... to make it flexible
juberti: I don't know how the syntax would look
hta: I'd like to look at the use cases
stefanh: any more comments
questions?
... ppl seem to be pretty happy with this
<dom> [the WebIDL has syntax errors, but I assume the editors will take care of it]
stefanh: does anyone have anything against integrating the API into the spec
fluffy: I can do that
stefanh: I conclude that we should start integrating the new stats API into the spec
<fluffy> I think the action is roughly me to move the API part of RTCWEBStatsv2.pdf proposal into spec
stefanh: nex topic is error handling
burn: I sent some slides to the list
<adam> http://www.w3.org/2011/04/webrtc/wiki/File:20130110error_handling.pdf
<dom> Error Handling slides
burn: before december there
hadn't been so much discussion about error handling
... the behaviour wasn't consistent between our documents
<jesup> Agreed justin's suggestion is an option and solves the size issue. If you need links to other parts, you could tell it to include the other part. Downside is complexity. Perhaps use selection only for adding non-baseline items (packet-level stats, histogram data, etc)
burn: I'll cover the main topics
<jesup> that was on the stats issue
burn: anant had proposed..
exceptions and callbacks
... detectable within < 50 ms should be an exception
fluffy: we talked about that and discarded it
burn: we throw an exception on a
bad argument
... and at illegal state
... otherwise we use the error callback
... I want to make sure we agree on this
hta: two comments
<dom> [based on https://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#error-names-0, the name should be INVALID_STATE_ERR rather than INVALID_STATE]
<dom> [TypeMismatch is enforced by WebIDL in any case]
hta: there might be other cases than bad arguments and state
burn: browsers could do better but our guidelines says don't do that
fluffy: last time we came to the conclusion time wasn't relevant here
<jesup> cullen++
fluffy: it's more about on which thread something is executed
<dom> +1 to juberti
juberti: I agree with fluffy that it shouldn't be based on a time
<jesup> juberti++
juberti: exceptions are programming errors and exceptions are runtime errors
second exceptions should be error callbacks
burn: we should change the quidelines to say that exceptions are thrown on programming errors
<dom> PROPOSED RESOLUTION: exceptions are thrown upon programming errors (for example invalid argument types or call in an invalid state); other errors are pushed as error callbacks
fluffy: I find this very abstract
burn: we need guidelines to avoid this discussion again
dom: I don't think we're changing the guidelines.. perhaps reformulating them
fluffy: I think we're missing too
much people in this call
... to change what we decided in a meeting with a lot more
people
<dom> " So decided that invalid_state will be a callback no exception" http://www.w3.org/2012/10/29-webrtc-minutes.html#item04
stefanh: could someone propose a change based on what we've talked about in this meeting
fluffy: I don't think we've agreed to anything here
stefanh: I think we need specific text in the form of an email
<hta> ACTION: justin to draft guideline text [recorded in http://www.w3.org/2013/01/10-webrtc-minutes.html#action01]
<trackbot> Created ACTION-79 - Draft guideline text [on Justin Uberti - due 2013-01-17].
burn: I went through the document
that doesn't have callbacks
... the resulting list is on slide 7
... I've underlined 4 of them
... but I don't remember fully what that meant
<dom> [updateIce makes reference to a "failure callback", but it's not clear which callback, since updateIce itself doesn't take a callback param http://dev.w3.org/2011/webrtc/editor/webrtc.html#widl-RTCPeerConnection-updateIce-void-RTCConfiguration-configuration-MediaConstraints-constraints ]
<juberti> +juberti
burn: question: do updateIce and addIceCandidate need callbacks
juberti: I don't think addIceCandidate needs callbacks
fluffy: thread boundaries might need to be crossed to find out if a candidate have a bad line number
<dom> (could also be an oniceerror event)
juberti: an exception wouldn't be appropriate in that case
dom: we colud have an ice error event
<adam> juberti: +1
juberti: we should report errors consistently between addIceCandidate() and, e.g., setLocalDesc
burn: I agree with juberti
juberti: events happen asyc that may not be a result of a function call
fluffy: I think we're fairly consistent on this
jesup: I think this sounds resonable
<jesup> justin++
<hta> justin said it
<fluffy> +1
juberti: we need the success callback to know when we can stop waiting for the error callback
<jesup> one function call -> leads to one callback (either error or success)
dom: the success callback might not give much.. we could go with one callback for both cases
burn: we've talked about this
before
... the first thing would always be to check for an error
dom: I remember that
conclusion
... but that might have been under other circumstanses
... in geolocation you get the position in the success
callback
<dom> [hixie recently highlighted the pain of having a useless parameter in pushState]
<juberti> same for createOffer and createAnswer
adambe: do we need to listen to the success cb and not continue before we get it or is it OK to ignore it
dom: I'm not aware of any other web api that does this, but this may not be the best time to bring up this discussion again
Zakim: ack me
<dom> "getIdentityAssertion Initiates the process of obtaining an identity assertion." http://dev.w3.org/2011/webrtc/editor/webrtc.html#widl-RTCPeerConnection-getIdentityAssertion-void
fluffy: ask ekr to clarify if getIdentityAssertion() need callbacks
burn: that operation is optional
<dom> [I think burn should send his analysis by email to kickstart the discussions :) ]
burn: I would encourage other ppl
to look at this as well
... anything that updates sdp needs to be queued
... if something needs to queue, it can't return right away
juberti: anything that mutaates sdp would fall into that bucket
stefanh: but not until createOffer is issued right?
juberti: I agree that addIceCandidate might need a callback for completeness
<dom> [the constructor should also have a callback then, shouldn't it?]
juberti: udateIce takes the same
arguments as the PeerConnection constructor
... and it doesn't have a error callback
... we might want to change addIceCandidate
<juberti> be right back
<dom> re updateIce, the spec says "an RTCError object of type INCOMPATIBLE_CONSTRAINTS is provided to the failure callback if the constraints could not be successfully applied."
fluffy: if you give a bad
password to the turn server
... we need an error for that case
<jesup> createDataChannel is supposed to be synchronous; it (for consistency with WebSockets) it fires an onopen when the channel opens and the object can't be used to transfer until then
burn: there are other proposals
for error handling
... ppl should review them
hta: juberti and I can look at it
with our chrome eyes
... I wolud like to hear an opinion from Mozilla
burn: anyone from Mozilla on the call?
<dom> ACTION: juberti to review needs for callback and errors callbacks in webrtc (with hta) [recorded in http://www.w3.org/2013/01/10-webrtc-minutes.html#action02]
<trackbot> Created ACTION-80 - Review needs for callback and errors callbacks in webrtc (with hta) [on Justin Uberti - due 2013-01-17].
<dom> ACTION: jesup to review needs for callback and errors callbacks in webrtc (with hta) [recorded in http://www.w3.org/2013/01/10-webrtc-minutes.html#action03]
<trackbot> Error finding 'jesup'. You can review and register nicknames at <http://www.w3.org/2011/04/webrtc/track/users>.
jesup: we will look at it as a team (at Mozilla)
<dom> ACTION: derf to review needs for callback and errors callbacks in webrtc (with hta) [recorded in http://www.w3.org/2013/01/10-webrtc-minutes.html#action04]
<trackbot> Created ACTION-81 - Review needs for callback and errors callbacks in webrtc (with hta) [on Timothy Terriberry - due 2013-01-17].
fluffy: we need to go through all calls and sort out what needs to produce errors
burn: we want this to be
consistent between the specs
... that's all about error handling for today
<matthew> (was on call, but have conflict now)
stefanh: we're moving on to the organizational section
<dom> ScribeNick: fluffy
Discussion around scribing procedures
<dom> A proposal on minute-takers for the WEBRTC WG meetings
see HTA proposal to list
We are not getting volunteers,, so we make a random list and work down it
Dan: when someone scribes, their names goes to bottom of the list. If someone is not there or presenting, they stay at top of the list
charis: plan to use that proposal
chairs wondering about WG LC in Q3 this year
hta: this depends on output of GUM
… can not sent GUM to LC until after face
stefanh: have dependencies on IETF specs
hta: some of it can be done without IETF being done, some of it we can not
dom: Our charter says we would be done by now and we need to update and review by AC
… A lot of people with expectation need fought estimates of when this will be done
… If we have reasonable objectives, it will easier to focus on getting things done
fluffy: suggest we write down a schedule to try and estimate when we would be done
<dom> ACTION: stefanh to develop more granular estimate for schedule of WebRTC with hta [recorded in http://www.w3.org/2013/01/10-webrtc-minutes.html#action05]
<trackbot> Created ACTION-82 - Develop more granular estimate for schedule of WebRTC with hta [on Stefan Håkansson - due 2013-01-17].
hta: It's not the work that is creating long time line , it is the periods of waiting. Possible to get done faster, if people, especially editors rapid turn around cycle and people, especially chairs, keep the formal things that need to be done lined up and moving. We need to work on that, as always
<dom> Proposed Interim Agenda from EKR
stefanh: EKR proposed to use more time on media capture on email to list. What do people think of that?
crikets: <silence>
juberti: makes sense to finish that
<dan_romascanu> still here
hta: The more we can get things like error handling sketch out, the better
stefanh: on the webrtc part of EKR's proposal
… chairs will use this as starting point for more detailed agenda
Fluffy asked about good standing process. Dom and other explained a bit. Chairs hope to never need to use it.