- From: Dominique Hazael-Massieux <dom@w3.org>
- Date: Thu, 10 Jan 2013 18:35:01 +0100
- To: public-webrtc <public-webrtc@w3.org>
Hi,
The minutes of our call today are available at:
http://www.w3.org/2013/01/10-webrtc-minutes.html
and copied as text below.
Dom
Web Real-Time Communications Working Group Teleconference
10 Jan 2013
[2]Agenda
[2]
http://www.w3.org/2011/04/webrtc/wiki/Teleconferences#Thu.2C_Jan_10_2013
See also: [3]IRC log
[3] http://www.w3.org/2013/01/10-webrtc-irc
Attendees
Present
+1.908.578.aabb, Dan_Burnett, hta, stefanh,
+972.9.957.aaee, Milan_Patel, dom, +91.22.39.14.aagg,
derf, Dan_Druta, +1.630.423.aajj, dan_romascanu?,
adambe, jesup, fluffy, +91.22.39.14.aall, juberti,
+1.831.440.aaoo, JeromeMarcon, nstratford,
+91.22.39.14.aapp, +44.190.881.aaqq, adam
Regrets
Chair
stefanh, hta
Scribe
adambe, fluffy
Contents
* [4]Topics
1. [5]Minutes approval
2. [6]Statistics API
3. [7]Error handling
4. [8]Scribing procedures
5. [9]schedule
6. [10]face to face meeting
* [11]Summary of Action Items
__________________________________________________________
<trackbot> Date: 10 January 2013
<stefanh> Agenda, and some stuff:
[12]http://www.w3.org/2011/04/webrtc/wiki/Teleconferences#Thu.2
C_Jan_10_2013
[12]
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>
[13]http://www.w3.org/2011/04/webrtc/wiki/Teleconferences#Thu.2
C_Jan_10_2013
[13]
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
Minutes approval
stefanh: we need to aprove the minutes
... any objections?
<stefanh> minutes:
[14]http://lists.w3.org/Archives/Public/public-webrtc/2012Dec/0
048.html
[14]
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
Statistics API
stefanh: and discuss how we use the f2f time in February
hta: I'm assuming that everyone has read the proposal
<dom> [15]Stats API proposal
[15]
http://lists.w3.org/Archives/Public/public-webrtc/2012Dec/att-0013/RTCWEBStatsv2.pdf
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
Error handling
burn: I sent some slides to the list
<adam>
[16]http://www.w3.org/2011/04/webrtc/wiki/File:20130110error_ha
ndling.pdf
[16]
http://www.w3.org/2011/04/webrtc/wiki/File:20130110error_handling.pdf
<dom> [17]Error Handling slides
[17]
http://www.w3.org/2011/04/webrtc/wiki/File:20130110error_handling.pdf
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
[18]https://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#e
rror-names-0, the name should be INVALID_STATE_ERR rather than
INVALID_STATE]
[18]
https://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#error-names-0
<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"
[19]http://www.w3.org/2012/10/29-webrtc-minutes.html#item04
[19] 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
[20]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
[21]http://dev.w3.org/2011/webrtc/editor/webrtc.html#widl-RTCPe
erConnection-updateIce-void-RTCConfiguration-configuration-Medi
aConstraints-constraints ]
[21]
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."
[22]http://dev.w3.org/2011/webrtc/editor/webrtc.html#widl-RTCPe
erConnection-getIdentityAssertion-void
[22]
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
[23]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
[24]http://www.w3.org/2013/01/10-webrtc-minutes.html#action03]
<trackbot> Error finding 'jesup'. You can review and register
nicknames at
<[25]http://www.w3.org/2011/04/webrtc/track/users>.
[25] http://www.w3.org/2011/04/webrtc/track/users%3E.
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
[26]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
Scribing procedures
Discussion around scribing procedures
<dom> [27]A proposal on minute-takers for the WEBRTC WG
meetings
[27]
http://lists.w3.org/Archives/Public/public-webrtc/2013Jan/0035.html
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
schedule
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
[28]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
face to face meeting
<dom> [29]Proposed Interim Agenda from EKR
[29]
http://lists.w3.org/Archives/Public/public-webrtc/2013Jan/0000.html
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.
Summary of Action Items
[NEW] ACTION: derf to review needs for callback and errors
callbacks in webrtc (with hta) [recorded in
[30]http://www.w3.org/2013/01/10-webrtc-minutes.html#action04]
[NEW] ACTION: jesup to review needs for callback and errors
callbacks in webrtc (with hta) [recorded in
[31]http://www.w3.org/2013/01/10-webrtc-minutes.html#action03]
[NEW] ACTION: juberti to review needs for callback and errors
callbacks in webrtc (with hta) [recorded in
[32]http://www.w3.org/2013/01/10-webrtc-minutes.html#action02]
[NEW] ACTION: justin to draft guideline text [recorded in
[33]http://www.w3.org/2013/01/10-webrtc-minutes.html#action01]
[NEW] ACTION: stefanh to develop more granular estimate for
schedule of WebRTC with hta [recorded in
[34]http://www.w3.org/2013/01/10-webrtc-minutes.html#action05]
Received on Thursday, 10 January 2013 17:35:15 UTC