- From: Dominique Hazael-Massieux <dom@w3.org>
- Date: Thu, 16 Oct 2014 14:49:22 +0200
- To: public-media-capture@w3.org
(I had sent this to a wrong email address two weeks ago — sorry for the
delay and thanks to Stefan for noticing their absence!)
Hi,
The minutes of our teleconf on October 2nd are available at:
http://www.w3.org/2014/10/02-mediacap-minutes.html
An (unfortunately somewhat incomplete) audio record is also available
at:
http://media.w3.org/2014/10/02-mediacapture.ogg
http://media.w3.org/2014/10/02-mediacapture.mp3
Minutes are also copied as text below.
Dom
Media Capture Task Force Teleconference
02 Oct 2014
[2]Agenda
[2]
http://lists.w3.org/Archives/Public/public-media-capture/2014Oct/0000.html
See also: [3]IRC log
[3] http://www.w3.org/2014/10/02-mediacap-irc
Attendees
Present
fluffy, burn, [IPcaller], annevk, stefanh, jib,
gmandyam, dom, +1.617.564.aadd, +46.1.07.14.aaee,
[Mozilla], ShijunSun, +1.214.343.aaff, adam,
+1.602.380.aagg, hta, ekr, justin, martin_thomson
Regrets
Chair
HTA, StefanH
Scribe
fluffy
Contents
* [4]Topics
1. [5]Agenda & minutes
2. [6]Slides on why to use Promises
3. [7]Slides on why not use Promises
4. [8]chairs schedule impact ?
5. [9]Decision Tree
* [10]Summary of Action Items
__________________________________________________________
<trackbot> Date: 02 October 2014
<stefanh> details for this call:
[11]http://lists.w3.org/Archives/Public/public-media-capture/20
14Oct/0000.html
[11]
http://lists.w3.org/Archives/Public/public-media-capture/2014Oct/0000.html
<scribe> scribenick: fluffy
Agenda & minutes
<stefanh> minutes to approve:
[12]http://lists.w3.org/Archives/Public/public-media-capture/20
14Aug/0049.html
[12]
http://lists.w3.org/Archives/Public/public-media-capture/2014Aug/0049.html
Call is being recorded
Resolution: minutes aproved
<dom> [13]JIB slides
[13]
http://lists.w3.org/Archives/Public/public-media-capture/2014Sep/att-0171/ModernizegUM.pdf
No changes to agenda
Slides on why to use Promises
jib presenting slides
EKR argued that current stuff is not broken and promises are at
best modelstly better. JIB argued that web world had moved to
promises as a better way.
<annevk> The main reason we want promises now is so that when
synchronous async/await syntax lands in JavaScript WebRTC can
use it and we don't need to keep hacking around with callbacks.
<annevk> Also, given that we want promises and getUserMedia is
still prefixed, I don't really understand what the pushback is
here. This can be done, it's trivial.
<hta1> annevk: if your argument depends on a future feature,
we're in trouble.
<annevk> hta1: I guess in this group I will refrain from that
argument then
<ekr> Shipping is a feature.
<annevk> Yes, shipping something coherent is too and you've had
a year now to adapt.
<annevk> And you still haven't shipped
<annevk> It's not like this is the problem
jutin asked if we still need to catch expceptions even if uses
Promises. JIB pointed out some error catching could be done in
Promises
<ekr> Yes, we still haven't shipped. The idea is to do so
without more bikeshedding
<annevk> The more you resist change and clinge to old habits,
the more of that you'll get
<ekr> Yes, I realize you see it that way
<annevk> It's happening now, no?
<ekr> It's cute how you think that if we just take this PR that
will be the end of the bikeshedding, not the beginning
<annevk> Are you always so condescending to your peers?
<burn> annevk, you were the first one to get personal. Feel
free to stop anytime.
<annevk> burn: you was meant to refer to the WG, not ekr
<mt_> I just love the collegial attitude here
<hta1> annevk, language that is regarded as insulting when
applied to a single person is no less insulting when applied to
a whole group.
<annevk> Fair, sorry for that
<juberti>
[14]https://docs.google.com/presentation/d/1mokzOqRrZIFDigQFonE
hPm5kdHmRVrrB8CZ6-jSJ2bw/edit?usp=sharing
[14]
https://docs.google.com/presentation/d/1mokzOqRrZIFDigQFonEhPm5kdHmRVrrB8CZ6-jSJ2bw/edit?usp=sharing
Slides on why not use Promises
Justin presenting slides
<dom> [15]Archived version of Justin's slides
[15]
http://lists.w3.org/Archives/Public/public-media-capture/2014Oct/att-0003/Thoughts_on_Promises__Public_.pdf
<annevk> I think at Mozilla we think we can deprecate callbacks
and remove them over time. We've been successful with that for
other features.
<annevk> XMLHttpRequest gets replaced by fetch()
<annevk> (which will handle more use cases, etc.)
<adam> annevk: If you're going to show contempt for the
standards process, I'd advise at least avoiding the
exceptionally poor form of doing so on the W3C IRC server.
<annevk> adam: what specifically are you referring to?
<adam> "I think at Mozilla…" -- I think at Mozilla, we can
implement whatever is speced.
<annevk> adam: how is that contempt for the standards process
to share experience on what is possible?
<annevk> adam: we have removed features before that have been
specced, because we realized that would be better for the web
<annevk> adam: and are still planning on doing so, e.g. with
showModalDialog()
<annevk> adam: that's not contempt, that's how we do
standards...
jib argues that moving to promises would not break people (by
using polyfills etc)
jib points out XHR does not really have the options we have
jlb points out we may have other issues around errors in last
call if we do not use promiases
jlb points out that if we tell people we are doing it one way
in 1.0 and changing in 1.1, that might actualy slow down
adption of webrtc
ekr does not think error handling is an issue that developers
are complaining about
jlb argue we could be done quickly - ekr does not feel this is
obvios - jlb argue will take some time to fix existing error
handling
justin - agree we would want to to update error objects so we
can add promises later
justin - dubios that the pull request to move to promises would
be the end of the conversation on this
justin feels doing this now would push out the tmeline to be
done
<annevk> Android is the wrong example. They can change APIs. We
can't on the web.
<annevk> Sometimes we're lucky we can. But now would be a good
time to get it right, before we ship.
<annevk> Also, this person is ignoring the point jib brought up
with regards to the current setup being wrong
<juberti> how can Android now change APIs?
<juberti> now=not
<juberti> Android needs to be able to ensure apps continue to
work.
hta - the reasons we don't inherit from Error is we don't have
a stable spec for it. We need a real ref to use this.
<ekr> annevk: that's an odd argument to be making at the same
time as you're arguing for breaking changes to the permissions
model about, say, geo
<mt_> [16]https://w3.org/TR/WebIDL ?
[16] https://w3.org/TR/WebIDL
<annevk> ekr: yes, sometimes we're lucky as I said, but it's a
painful process
<annevk> ekr: it's better to be right from the start then try
to make changes later
<annevk> ekr: especially if it's known we need to make changes
some existing specs have normative ref to private moz repo for
error specifiction
Justin as when promises would be usable in FF
<annevk> Promises is shipping in stable
<dom> ["how soon would Firefox Hello switch to a promise
version?" might be another way to phrase juberti question]
jib - Firefox already has a version of FF that supports
promises for gum in private branch
<annevk> If we agree to promises now, we can do that for the
next version
<ekr> well, when the next version is in 18 weeks
<annevk> Yeah, sorry
Jusitn - does not think it will be free to swtich to this. If
it is so simple, we can add it simply later
<mt_> cost[now] < cost[later]
JIB - does not really change underlying implmentations
<jib> Working promise patch for mediaDevices.getUserMedia:
[17]https://bugzilla.mozilla.org/page.cgi?id=splinter.html&bug=
1033885&attachment=8492555
[17]
https://bugzilla.mozilla.org/page.cgi?id=splinter.html&bug=1033885&attachment=8492555
<annevk> The vendor prefix negates that argument imo
ekr - argue that this would delay doc 18 weeks as we need to
wait for implemetiotns before moving doc forward
anne - Promises are shipping in all browses now. They are
stable. True that ecma 6 script is hosted on moz servers since
the official spec is PDF. You can just ref webidl.
scribe: if we change now, in the futre we can move to a version
of the API that has one way to do it not two
... seems weird that people agree we want to move to promises
eventuall but don't understand resitance to doing it now
<ekr> I will say that the prefix change is trivial
scribe: ther will library impact from prefix change so better
to do now rather than to it in multiple steps later
<annevk> ekr: we have found that unprefixing often breaks
things
<jib> Oh, I forgot, most of my patch is actually adding the
mediaDevices interface itself, so the actual code is much less
<annevk> ekr: especially with APIs
<ekr> annevk: that's fair. but we already have polyfills that
handle Chrome vs. Firefox, so I have some confidence we can get
this done
<annevk> ekr: we have those for Fullscreen too
<annevk> ekr: it's terrible :-(
adam - These aproach are funcitonal isomoric. So this is an
asthetic decisions. So agree shipping is a feature. We know
what we have now works. The argumrent we can polyfill cuts both
ways
<gmandyam> Question for jib: What about functions hanging off
of EventTargets (e.g. addTrack(), getTrackById())?
<ekr> annevk: yeah, I know it's pretty bad
<ekr> annevk: especially, since we have to also bridge small
API differences
gmandyam - would the event targets in webrtc be moved to
targets ? JIB - it depends. Things that can fire multiple times
proabbly best for events. Some other things probabbly not.
Things like addTrack need to move to async so will brak
backwards compat already
<gmandyam> Clarification: I wasn't asking jib about event
targets themselves (e.g. MediaStream), but the asynch.
functions that hang off of the event targets
(MediaStream.someFunc()).
mt - This is being set up in very adverserial way. We are
attacking it in way that makes me very uncofortbale. Its hard
to convince people to pay down technical debt which is what you
are doing.
scribe: the callbacks and error stuff are technical debt. It is
spec technical debt. What concenrs him the most is API
usability.
... Promises are a win (not big win) from API usabilyt point of
view
<mt_> Promises won't hold anything up inherently
<burn> fluffy asked whether use or lack of use of promises will
slow us down in the W3C Last Call process.
<annevk> You will certainly get one formal objection less if
you adopt promises
dom - think it is clear that TAG will send comments on this if
we don't use promises
scribe: we would probbaly argure we have enough deployment we
think this is best
... gut feel is promises would be smother
... but we should make decisiosn based on what would make the
web the best, not what would make our lives easy
<burn> s/smother/smoother/ in fluffy's minutes :)
chairs schedule impact ?
chairs - could be easy but might be lots of things hiding in
details so hard to know right now
Decision Tree
<dom> [18]Harald's decision tree
[18] http://www.w3.org/mid/542A62A4.2090606@alvestrand.no
HTA: on first question feel people want yes
... on seond question feel people sharply divided
<ekr> yes, I think I understand
chairs: proposal to group is we have a YES on 1
<dom> [despite my longstanding push to finalize this damn spec,
I have to come to a personal conclusion that moving to promise
now (i.e. before LC) would be the better option]
resolution: consenssus is yes on we want promises eventually
<gmandyam> Qualcomm Innovation Center votes in favor of Level 2
<Cow_woC> For what it's worth, I'm +1 for Promises before LC.
gmandyam - can we get a colective view from each organization ?
fluffy: quetion about if we did this later would we later
depricate callbacks
jib: future spec would doc both in spec if we do it later
justin: could have callback in 1.0 then in 1.1 we could add
Promises and say callbacks were complicated
dom: the two browsers that have not shipped may only want to do
speced version not callbacks in this case
jib - whats not clear in decisons tree is how we deal callbacks
over time
<annevk> I strongly disagree; we've managed to remove many APIs
over time
ekr: dont' see world wehre we remove these APIs
jib: seem prefixes deal with this and several of the API are
not implemented yet i
ekr: argue that exisitn PAI need to continu to have callbacks
<annevk> ekr: are you suggesting we'd keep supporting
mozGetUserMedia() forever too, then?
ShijunSun: lets keep focused on gum - webrtc is a seperate
issue
anne: If callbacks don't disapear, do the prefx disapear?
ekr: having prefix disapear is differnt than this. Chrome has
depricated many webkit api
ShijunSun: for promises think it is a good coding style. Good
idea to adopt. But what is imeplemented is also important. We
don't want to break interop - that is important for developers.
ekr: wants to never have this dicsuions again.
<Cow_woC> :)
ekr: propose we have promise version of all API and agree not
to depricated callback based apraoches for stuff that is in use
today
<Cow_woC> ekr: I can promise you that if Promises are not
adopted it will come up again :)
ekr: not willing to abandon existing callbacks in next few
years because people use them
<annevk> People also use mozGetUserMedia(); I doubt there would
be consensus on not deprecating that after we ship something
unprefixed within the Mozilla community
<ekr> annevk: I'm fine with discussing deprecating
mozgetusermedia
<annevk> Or within the Chrome community for that matter
<ekr> I'm solely talking about the api calling style
<annevk> If you have to change one of those things anyway, it
seems fairly trivial to have both adjusted.
<ekr> annevk: well, I think I've explained why I don't think
that's true.
<annevk> Just post a page online that outlines the transition
you need to do.
<annevk> I don't think your experience matches what I've seen
for many other platform APIs
<ekr> Well, you don't have to agree.
chairs propose consensus of
<annevk> I don't
<ekr> Yes, I'd gathered that.
1) we add promises to version for LC
2) we keep callbacks for things that use them
<mt_> I'll note that our decision to make error callbacks
mandatory might have to be revisited
<mt_> but that's a small point only
<Cow_woC> ekr: What about the "our callbacks our broken" slide?
Don't we need to modify error handling in callbacks either way?
<jib> both versions of what? getUserMedia and enumeratDevices
and applyConstraints? Does anyone implement the latter?
chairs: will find someone to write up this proposal and bring
to group
<annevk> I think a number of people said that they didn't want
both, no?
<ekr> annevk: yes, I tink they did.
jib: aks ehin ones have callbacsk
chairs: juse userMedia
ekr: ask if we going to hear people asking for remove
getusermedia
... the one on getusermedia can be just promises but navigator
need to have callbacks
end fo call
Received on Thursday, 16 October 2014 12:49:38 UTC