W3C home > Mailing lists > Public > public-media-capture@w3.org > October 2014

[minutes] October 2nd teleconf

From: Dominique Hazael-Massieux <dom@w3.org>
Date: Thu, 16 Oct 2014 14:49:22 +0200
Message-ID: <1413463762.4537.191.camel@cumulustier>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:26:30 UTC