Media Capture Task Force Teleconference

<trackbot> Date: 02 October 2014

<stefanh> details for this call: http://lists.w3.org/Archives/Public/public-media-capture/2014Oct/0000.html

<scribe> scribenick: fluffy

Agenda & minutes

<stefanh> minutes to approve: http://lists.w3.org/Archives/Public/public-media-capture/2014Aug/0049.html

Call is being recorded

Resolution: minutes aproved

<dom> JIB slides

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> https://docs.google.com/presentation/d/1mokzOqRrZIFDigQFonEhPm5kdHmRVrrB8CZ6-jSJ2bw/edit?usp=sharing

Slides on why not use Promises

Justin presenting slides

<dom> Archived version of Justin's slides

<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_> 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: 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> Harald's decision tree

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