14:45:27 <RRSAgent> RRSAgent has joined #mediacap
14:45:27 <RRSAgent> logging to http://www.w3.org/2013/06/05-mediacap-irc
14:45:29 <trackbot> RRSAgent, make logs public
14:45:29 <Zakim> Zakim has joined #mediacap
14:45:31 <trackbot> Zakim, this will be MCAP
14:45:31 <Zakim> I do not see a conference matching that name scheduled within the next hour, trackbot
14:45:32 <trackbot> Meeting: Media Capture Task Force Teleconference
14:45:32 <trackbot> Date: 05 June 2013
14:45:39 <dom> Zakim, this will be FUTURE
14:45:40 <Zakim> ok, dom; I see UW_WebRTC(FUTURE)11:00AM scheduled to start in 15 minutes
14:45:58 <Josh_Soref> Zakim, code
14:45:58 <Zakim> I don't understand 'code', Josh_Soref
14:46:03 <Josh_Soref> Zakim, code?
14:46:04 <Zakim> the conference code is 388873 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), Josh_Soref
14:53:41 <annevk> annevk has joined #mediacap
14:55:07 <Zakim> UW_WebRTC(FUTURE)11:00AM has now started
14:55:16 <Zakim> + +30210818aaaa
14:55:26 <Yahui> Yahui has joined #mediacap
14:55:32 <annevk> Zakim, passcode?
14:55:32 <Zakim> the conference code is 388873 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), annevk
14:56:05 <Zakim> + +91.22.39.14.aabb
14:56:11 <Zakim> +[IPcaller]
14:56:18 <fjh> zakim, [IPcaller] is me
14:56:18 <Zakim> +fjh; got it
14:56:26 <fjh> Present+ Frederick_Hirsch
14:56:38 <Zakim> +stefanh
14:57:12 <Zakim> +Josh_Soref
14:57:31 <Zakim> +??P25
14:57:36 <dom> Zakim, ??P25 is me
14:57:36 <Zakim> +dom; got it
14:57:50 <Zakim> +??P24
14:57:57 <Josh_Soref> scribe: Josh_Soref
14:58:00 <Zakim> +[IPcaller]
14:58:38 <annevk> Zakim, who is making noise?
14:58:39 <adam> adam has joined #mediacap
14:58:41 <Josh_Soref> Zakim, who is on the call?
14:58:41 <Zakim> On the phone I see +30210818aaaa, +91.22.39.14.aabb, fjh, stefanh, Josh_Soref, dom, ??P24, [IPcaller]
14:58:44 <dom> Zakim, [IPcaller] is probably annevk
14:58:44 <Zakim> +annevk?; got it
14:58:48 <Zakim> annevk, listening for 10 seconds I heard sound from the following: +91.22.39.14.aabb (4%), stefanh (34%)
14:59:03 <Josh_Soref> Zakim, where is +91?
14:59:03 <Zakim> country code 91 is India
14:59:30 <Zakim> +[Mozilla]
14:59:50 <Josh_Soref> Zakim, who is on the call?
14:59:50 <Zakim> On the phone I see +30210818aaaa, +91.22.39.14.aabb, fjh, stefanh, Josh_Soref, dom, ??P24, annevk?, [Mozilla]
14:59:55 <adam> Zakim, [Mozilla] is me
14:59:55 <Zakim> +adam; got it
14:59:58 <Josh_Soref> Zakim, who is making noise?
14:59:59 <stefanh> propsed agenda: http://lists.w3.org/Archives/Public/public-media-capture/2013Jun/0009.html
15:00:03 <Zakim> +Jim_Barnett
15:00:09 <Zakim> Josh_Soref, listening for 10 seconds I heard sound from the following: Josh_Soref (4%), ??P24 (85%)
15:00:20 <dom> Zakim, ??P24 is annevk
15:00:20 <Zakim> +annevk; got it
15:00:25 <annevk> Zakim, annevk holds Alex
15:00:25 <Zakim> 'annevk' is ambiguous, annevk
15:00:30 <annevk> Zakim: I know!
15:00:38 <dom> Zakim, annevk? is really [IPcaller]
15:00:38 <Zakim> +[IPcaller]; got it
15:00:39 <adambe> adambe has joined #mediacap
15:00:41 <Zakim> +gmandyam
15:00:43 <Josh_Soref> Zakim, who is on the call?
15:00:43 <Zakim> On the phone I see +30210818aaaa, +91.22.39.14.aabb, fjh, stefanh, Josh_Soref, dom, annevk, [IPcaller], adam, Jim_Barnett, gmandyam
15:00:51 <dom> Zakim, annevk also holds Alex
15:00:51 <Zakim> +Alex; got it
15:00:54 <Zakim> + +46.1.07.14.aacc
15:00:56 <JimB> JimB has joined #mediacap
15:01:09 <slightlyoff> slightlyoff has joined #mediacap
15:01:10 <Josh_Soref> Zakim, where is +302?
15:01:10 <Zakim> country code 30 is Greece
15:01:15 <jib> I'm calling from skype
15:01:28 <dom> Zakim, [IPcaller] is jib
15:01:28 <Zakim> +jib; got it
15:01:31 <stefanh> zakim, aacc is adambe
15:01:31 <Zakim> +adambe; got it
15:01:45 <annevk> Josh_Soref: Dini_Martini
15:01:58 <Josh_Soref> Zakim, aaaa is Dini_Martini
15:01:58 <Zakim> +Dini_Martini; got it
15:02:16 <Josh_Soref> Zakim, who is on the call?
15:02:16 <Zakim> On the phone I see Dini_Martini, +91.22.39.14.aabb, fjh, stefanh, Josh_Soref, dom, annevk, jib, adam, Jim_Barnett, gmandyam, adambe
15:02:19 <Zakim> annevk has annevk, Alex
15:02:26 <Zakim> +ekr
15:02:32 <Zakim> + +44.207.346.aadd
15:02:42 <jesup> jesup has joined #mediacap
15:02:48 <Josh_Soref> Josh_Soref has changed the topic to: agenda: http://lists.w3.org/Archives/Public/public-media-capture/2013Jun/0009.html - code: 388873
15:02:56 <Josh_Soref> topic: Agenda
15:03:08 <Josh_Soref> stefanh: i posted the agenda earlier
15:03:20 <Cow_woC> Hi guys :)
15:03:21 <Josh_Soref> topic: Short intro+overview of Futures
15:03:25 <slightlyoff> howdy all
15:03:28 <Josh_Soref> stefanh: annevk, you sent out an email on futures
15:03:36 <Josh_Soref> ... but maybe you could talk about it a bit
15:03:41 <Josh_Soref> ... if there's a need for clarification?
15:03:47 <Josh_Soref> Zakim, mut eme
15:03:47 <Zakim> I don't understand 'mut eme', Josh_Soref
15:03:48 <dom> -> http://lists.w3.org/Archives/Public/public-media-capture/2013May/0111.html Anne's intro to Futures in WebRTC
15:03:49 <Zakim> + +1.610.889.aaee
15:03:52 <Josh_Soref> Zakim, mute me
15:03:52 <Zakim> Josh_Soref should now be muted
15:04:03 <Josh_Soref> annevk: based on research largely done by slightlyoff
15:04:04 <ekr> ekr has joined #mediacap
15:04:17 <Josh_Soref> ... the JavaScript community has been using them in Libraries for 4 years
15:04:20 <Josh_Soref> ... they allow for composition
15:04:28 <jesup> zakim: aaee is me
15:04:30 <Josh_Soref> ... they avoid the pyramid of doom
15:04:34 <dom> Zakim, aaee is jesup
15:04:34 <Zakim> +jesup; got it
15:04:36 <Josh_Soref> ... they allow for better style
15:04:46 <Zakim> +Dan_Burnett
15:04:48 <Josh_Soref> ... in order to improve the Platform in the future
15:04:52 <Josh_Soref> ... they improve
15:04:57 <Josh_Soref> slightlyoff: hi, Alex Russel
15:05:05 <Josh_Soref> ... the intuition behind Promises/Futures
15:05:18 <Josh_Soref> ... is that it's very common to see slight variation
15:05:21 <Josh_Soref> ... in functions
15:05:29 <Josh_Soref> ... even though you don't see XXX
15:05:36 <Josh_Soref> ... there's a divergence in patterns of return values
15:05:47 <Josh_Soref> ... the hope is that Promises/Futures will provide a uniform contract
15:05:49 <Josh_Soref> ... for every spec to use
15:05:57 <Josh_Soref> ... whenever it wants to return a single value that needs to be asynchronous
15:06:11 <Josh_Soref> annevk: are Futures generally understood?
15:06:17 <Josh_Soref> ... do people have questions on the basics?
15:06:33 <Josh_Soref> jib: i think a quick demo would be useful
15:06:33 <jesup> jib was speaking
15:06:39 <slightlyoff> Josh_Soref: a divergence in syntactic patter, you see differences in semantics -- however we see wide divergence in syntax too!
15:06:41 <Josh_Soref> s/jib was speaking//
15:06:54 <Josh_Soref> annevk: it's a programming pattern
15:07:03 <Josh_Soref> slightlyoff: in many cases,  you'll have a function that takes a couple of callbacks
15:07:06 <Josh_Soref> ... a success and error
15:07:14 <Josh_Soref> ... if it's e.g. opening a device for i/o
15:07:18 <Josh_Soref> ... think about the Promise
15:07:25 <Josh_Soref> ... it overloads the void-return type
15:07:39 <Josh_Soref> ... it alleviates issues w/ functions that use events
15:07:40 <Zakim> + +1.425.936.aaff
15:07:47 <Josh_Soref> ... this semantic dead zone
15:07:56 <Josh_Soref> ...  you call your operation not passing the callbacks to the function
15:08:04 <Josh_Soref> ... and then you call .then() on the promise w/ your callbacks
15:08:13 <Josh_Soref> ... Promises have well documented modes for chaining
15:08:17 <Josh_Soref> ... once more things use them
15:08:22 <Josh_Soref> ... instead of providing callbacks up front
15:08:31 <Josh_Soref> ... you provide the callbacks when you're ready
15:08:42 <Josh_Soref> ... there's a question that usually arises about compatibility
15:08:52 <Josh_Soref> ... say someone uses the current api that has callbacks
15:08:52 <Josh_Soref> ... what then?
15:08:57 <Josh_Soref> ... the happy accident of most DOM apis
15:09:01 <Josh_Soref> ... is that they return void today
15:09:26 <Josh_Soref> ... we can have the function return a promise instead of a void and map them directly
15:09:29 <Josh_Soref> ... for new APIs
15:09:37 <jesup> ekr
15:09:40 <Josh_Soref> ekr: based on reading what i see on the web
15:09:48 <Josh_Soref> ... it's possible to mint futures
15:09:56 <Josh_Soref> ... there's support for wrapping APIs in JS
15:09:56 <Zakim> + +972.9.957.aagg
15:10:01 <Josh_Soref> slightlyoff: correct
15:10:05 <gmandyam> gmandyam has joined #mediacap
15:10:06 <Josh_Soref> ... one way to think about futures
15:10:13 <Josh_Soref> ... they're in the style of APIs
15:10:15 <annevk> Yes, http://dom.spec.whatwg.org/#introduction-to-the-future does that for e.g. XMLHttpRequest
15:10:17 <annevk> fjh: ^^
15:10:22 <Josh_Soref> ... you can use this
15:10:24 <slightlyoff> https://github.com/slightlyoff/Futures/blob/master/README.md
15:10:26 <Josh_Soref> ... you can new Future yourself
15:10:30 <Josh_Soref> ... there's examples in the readme
15:10:41 <mreavy> mreavy has joined #mediacap
15:10:42 <Josh_Soref> ... anyone can wrap any api with this type
15:10:49 <Josh_Soref> ... the value isn't that anyone can't do it themselves
15:10:53 <juberti> juberti has joined #mediacap
15:11:00 <dan_romascanu> dan_romascanu has joined #mediacap
15:11:00 <Josh_Soref> ... but once they learn to use them, they can use them everywhere
15:11:11 <Josh_Soref> stefanh: more questions?
15:11:35 <Josh_Soref> topic: Implementation plans/status
15:11:41 <Josh_Soref> stefanh: there were things on the ML from MS and Google
15:11:49 <Josh_Soref> ... i don't know if Travis is on the call
15:11:55 <Josh_Soref> ... or anyone from MS
15:11:57 <jesup> q+
15:12:06 <Josh_Soref> ack jesup
15:12:12 <Josh_Soref> jesup: Mozilla is working on Futures
15:12:18 <Josh_Soref> ... but we don't have a release date planned
15:12:36 <Josh_Soref> ... we're working on it, it isn't a burning priority
15:12:52 <Josh_Soref> ... given the ability to polyfill around it
15:13:04 <Josh_Soref> stefanh: anyone from Google?
15:13:09 <Josh_Soref> slightlyoff: we're planning on implementing
15:13:17 <Josh_Soref> ... we don't currently have the feature in our releases
15:13:23 <Josh_Soref> ... but we have a team in Tokyo implementing in Blink
15:13:34 <Josh_Soref> ... we're viewing this as the basis for all our new Asynchronous APIs
15:13:46 <Josh_Soref> ... as we work through more of our proposals on the Blink ML,  you'll see this more often
15:14:01 <Josh_Soref> stefanh: to summarize from Travis, MS doesn't comment on future features
15:14:38 <Josh_Soref> annevk: we're similarly aligned with Google, we see it as the basis for all our new APIs
15:14:52 <Josh_Soref> ... w'ere not sure where WebRTC is on the dividing line between new-Futures or old
15:14:57 <Josh_Soref> ... it's definitely where we want to go
15:15:06 <Josh_Soref> juberti: Justin, Google
15:15:11 <Josh_Soref> ... following up on slightlyoff
15:15:16 <Josh_Soref> ... we're trying to ship WebRTC 1
15:15:27 <Josh_Soref> ... it'll probably be just before the end of year before Futures hit stable for Chrome
15:15:43 <Josh_Soref> annevk: not sure what the launch planners want
15:15:48 <Josh_Soref> ... but the API is pretty simple
15:15:52 <mreavy> q+
15:15:56 <annevk> Josh_Soref: was slightlyoff
15:16:05 <Josh_Soref> s/annevk/slightlyoff/
15:16:08 <dom> s/annevk: not sure/slightlyoff: not sure
15:16:14 <Josh_Soref> ekr: IndexedDB is shipping w/o Futures
15:16:31 <Josh_Soref> slightlyoff: IndexedDB is largely acknowledged as an API failures
15:16:35 <Josh_Soref> s/failures/failure/
15:16:41 <annevk> IndexedDB was shipping before Futures was spec concept...
15:16:46 <Josh_Soref> ... we're implementing Futures because WebCrypto needs it
15:16:51 <Josh_Soref> ... i know WebRTC wants to move
15:16:59 <Josh_Soref> ... the question is do you want it now?
15:17:01 <Josh_Soref> ... it's going to happen
15:17:06 <Josh_Soref> ekr: what do you mean it's going to happen
15:17:13 <Josh_Soref> ... that's a pretty strong assertion
15:17:16 <Josh_Soref> ... what's the basis?
15:17:25 <Josh_Soref> slightlyoff: i know annevk and i will continue the conversation @TAG
15:17:28 <Josh_Soref> ... w/ the leads of this WG
15:17:32 <Josh_Soref> s/WG/TF/
15:17:42 <Josh_Soref> ... and i expect that to create evolution at least related to Futures
15:17:47 <stefanh> q?
15:17:48 <Josh_Soref> ... that's the starting point of that discussion
15:17:55 <dom> (I think a stronger argument would be that implementors would necessarily want it to ship with futures)
15:17:56 <Josh_Soref> ekr: that's not the same as it's going to happen
15:18:00 <Josh_Soref> slightlyoff: Futures will be in the platform
15:18:03 <Josh_Soref> ... there's no controversy
15:18:13 <Josh_Soref> ... annevk and i will raise this to this TF
15:18:24 <Josh_Soref> ekr: slightlyoff said "you can change to Futures now, or you can change to Futures later"
15:18:31 <Josh_Soref> ... but i think lots of stuff will never change
15:18:41 <Josh_Soref> ekr: what if we change to Futures never?
15:18:51 <Josh_Soref> ... is that off the table?
15:18:56 <Josh_Soref> annevk: it's technically on the table
15:19:04 <Josh_Soref> ... but APIs will be converted into using Futures
15:19:09 <Josh_Soref> ... because it's far more convenient
15:19:18 <Josh_Soref> ... it will happen for callback things and broken event model things
15:19:27 <Josh_Soref> ekr: this is a feature that we've yet to deploy at all
15:19:34 <Josh_Soref> ... we don't have experience with it in the platform
15:19:41 <Josh_Soref> annevk: we have experience with it in JS libraries
15:19:47 <Josh_Soref> ekr: i've worked with Twisted
15:19:53 <Cow_woC> Question: what about the exception stack-trace when using Futures?
15:19:58 <Josh_Soref> ... it's hard to follow/incomprehensible
15:20:06 <Josh_Soref> ... it seems like it's the Platform-Du-Jour
15:20:23 <Josh_Soref> s/Platform/Fashion/
15:20:24 <Cow_woC> The existing callback mechanism isn't much better, to be sure, but can this be improved?
15:20:41 <Josh_Soref> slightlyoff: changing your return type from `void` to `Promise` isn't difficult
15:20:55 <Josh_Soref> ... you could argue that doing it for v1 isn't in your short term interest
15:21:03 <Josh_Soref> ... my best analysis is that there will be a change in your API
15:21:09 <stefanh> q?
15:21:14 <Josh_Soref> annevk: this has been a research subject since the 70s
15:21:22 <Josh_Soref> slightlyoff: almost every major JS library that's deployed
15:21:26 <Josh_Soref> ... uses these for Async operations
15:21:29 <Josh_Soref> ... almost exclusively
15:21:38 <Josh_Soref> ... there's a large movement in the community to make them compatible
15:21:42 <Josh_Soref> ... PromisesA+
15:21:51 <Josh_Soref> ... the design we're proposing is compatible w/ that
15:21:57 <Josh_Soref> ... this is an ongoing sea-change
15:22:01 <Josh_Soref> ack mreavy
15:22:11 <Josh_Soref> mreavy: i'm concerned about tying the delivery of WebRTC
15:22:14 <Josh_Soref> ... to Futures
15:22:20 <Josh_Soref> ... we have a fair bit of Risk in the schedule right now
15:22:29 <Josh_Soref> ... IMO, if we're adding more risk, there should be a lot of benefit for it
15:22:35 <Josh_Soref> ... i don't see a lot of benefit for tying it to v1
15:22:50 <Josh_Soref> annevk: i don't see the risk you guys are seeing
15:22:55 <Josh_Soref> ... which makes debating this hard
15:23:01 <Josh_Soref> mreavy: it hasn't been implemented yet
15:23:16 <Josh_Soref> slightlyoff: it's possible in Blink to take the JS parser and whack it into the runtime and go
15:23:20 <Josh_Soref> ... the implementation risk for this
15:23:30 <Josh_Soref> ... it's worth contrasting this w/ the implementation risk w/ IndexedDB
15:23:38 <jesup> q+
15:23:43 <Josh_Soref> ... despite specifying just as complicated request model
15:23:51 <Josh_Soref> ... the benefit is more compatible w/ future specs going forward
15:23:59 <Josh_Soref> ... given DOM and TC39 have bought into this same design
15:24:04 <ekr> q+
15:24:06 <Josh_Soref> ... this is going to be a key piece of the platform going forward
15:24:12 <Josh_Soref> ... it doesn't seem to be much risk
15:24:14 <Josh_Soref> ack jesup
15:24:14 <mreavy> q+
15:24:32 <Josh_Soref> jesup: i see there might not be too much risk implementing starting in the near future
15:24:43 <Josh_Soref> ... but Chrome has PeerConnection beyond the pref-guard
15:24:53 <Josh_Soref> ... and Firefox will have it in 22 (which is @B4 today)
15:24:58 <Josh_Soref> ... this isn't a change we can do for 22
15:25:08 <Josh_Soref> ... if we go out w/o this, and Chrome goes out w/o this
15:25:12 <dom> [I think the argument is that Future can be defined to be backward compatible with the existing callback model]
15:25:15 <Josh_Soref> ... anyone writing an app will have to polyfill already
15:25:29 <Josh_Soref> slightlyoff: "will it accelerate your timeline to getting it out to end users"
15:25:39 <Josh_Soref> ... if you're willing to add the relatively trivial return type
15:25:45 <juberti> q+
15:25:50 <Josh_Soref> ... and get it out in 23
15:25:55 <Josh_Soref> ... then not much risk
15:26:01 <Josh_Soref> ... but if other people can't make the change quickly
15:26:06 <Josh_Soref> ... then it's up to your best judgement
15:26:10 <Josh_Soref> ack ekr
15:26:21 <Josh_Soref> ekr: there are two kinds of risk here
15:26:30 <Josh_Soref> ... implementations don't have code
15:26:41 <Josh_Soref> ... maybe we shim stuff, but i don't think Chrome/Firefox will do that
15:26:56 <Josh_Soref> ... second, just because some people have bought in, doesn't mean people won't change later
15:27:02 <Josh_Soref> ... given that it should be polyfillable
15:27:13 <Josh_Soref> annevk: you also have the third risk of the same shitstorm as IndexedDB
15:27:20 <Josh_Soref> ekr: that people won't like the API
15:27:23 <Josh_Soref> annevk: correct
15:27:30 <Josh_Soref> ekr: my concern about people not liking the API
15:27:39 <Josh_Soref> ... is #133 on my list of concerns
15:27:47 <Josh_Soref> slightlyoff: why isn't that a hot topic?
15:27:55 <Josh_Soref> ekr: there are special concerns that aren't syntactic
15:28:07 <Josh_Soref> slightlyoff: confused by your answer
15:28:16 <Josh_Soref> ekr: building WebRTC has involved a lot of compromises
15:28:22 <Josh_Soref> ... no one is quite happy
15:28:27 <Josh_Soref> ... there are things we're living with
15:28:31 <Josh_Soref> ack mreavy
15:28:42 <Josh_Soref> mreavy: a lot of what ekr said rings true with me
15:28:50 <Josh_Soref> ... my big concern is Death by a thousand cuts
15:28:58 <Josh_Soref> ... there are a lot of things we can put in v1
15:29:02 <Josh_Soref> ... i'm hoping to descope
15:29:12 <Josh_Soref> ... only putting things in if they're necessary
15:29:18 <Josh_Soref> ... i'm looking for the big value-add
15:29:25 <Josh_Soref> ack juberti
15:29:29 <Josh_Soref> juberti: i share the same perspective
15:29:38 <Josh_Soref> ... the API, is a compromise in many ways
15:29:41 <Josh_Soref> ... i agree this is more elegant
15:29:47 <Josh_Soref> ... we have existing code that is out there
15:29:48 <jib> q+
15:29:53 <Josh_Soref> ... and they'll be sad if it stops working
15:30:04 <Josh_Soref> ... we could carry around support code for that
15:30:04 <dom> q+
15:30:10 <Josh_Soref> ... but it will need to be supported forever
15:30:15 <Josh_Soref> ... i'm not very excited about that
15:30:19 <Josh_Soref> ... we're trying to finish v1
15:30:26 <Josh_Soref> ... doesn't mean there won't be v2
15:30:31 <Josh_Soref> annevk: that's a BS argument
15:30:35 <Josh_Soref> ... an API lasts forever
15:30:39 <Josh_Soref> ... if you want to ship a v1
15:30:44 <Josh_Soref> ... you have to do it right
15:30:49 <Josh_Soref> ... if that means a 1 month delay
15:30:52 <Josh_Soref> ... that isn't too bad
15:31:01 <Josh_Soref> ... given the long term cost in supporting it
15:31:03 <Josh_Soref> ... i sympathize
15:31:08 <Josh_Soref> ... but it's important to do the right thing
15:31:16 <Josh_Soref> juberti: that ship has sailed
15:31:20 <Josh_Soref> ... we already shipped v1
15:31:24 <Josh_Soref> ... we'll ship a compat shim
15:31:29 <Josh_Soref> annevk: that's not true
15:31:33 <Josh_Soref> ... there's only one implementation
15:31:39 <Josh_Soref> ekr: you don't seriously expect a change in Firefox
15:31:43 <Josh_Soref> ... between B4 and 22
15:31:55 <Josh_Soref> annevk: we could decide to not ship it
15:31:58 <Josh_Soref> mreavy: i hope that's not something we'd do
15:32:13 <Josh_Soref> slightlyoff: normally  "if it's not ready, it's not ready - you can always get on the next train"
15:32:21 <Josh_Soref> juberti: we've been shipping since Chrome 21
15:32:27 <Josh_Soref> ... this is API churn for developers
15:32:33 <Josh_Soref> ... who have been running this code for over a year
15:32:41 <Josh_Soref> slightlyoff: i'd like to posit a couple of things here
15:32:46 <Josh_Soref> ... the future is bigger than the past
15:32:49 <stefanh> q?
15:32:54 <Josh_Soref> ... i've heard the argument about "backwards incompatible changes"
15:33:02 <Josh_Soref> ... and i've heard the argument of "no there won't, there will be legacy"
15:33:06 <Josh_Soref> ... but you can't make both arguments
15:33:13 <Josh_Soref> ... i understand different people are arguing different things
15:33:17 <ekr> q+
15:33:19 <Zakim> - +44.207.346.aadd
15:33:21 <Cow_woC> ... seriously? The number of production-grade applications running on top of WebRTC could be counted on a single hand, could they not? Certainly there are 1000s of people playing with it, but production-grade releases?
15:33:23 <Josh_Soref> ... the question is about making the Platform consistent for everyone
15:33:29 <Josh_Soref> ... if WebRTC becomes popular
15:33:35 <Josh_Soref> ... and everyone else uses Futures
15:33:44 <jesup> I also hear people arguing that we can a) never change a shipped API, and b) it's not that big a deal to change a shipped api
15:33:45 <Josh_Soref> ... then there's more pressure on WebRTC to become compatible
15:33:51 <Josh_Soref> ... either everyone uses shims
15:33:56 <Josh_Soref> ... or you need to ship a new API
15:34:02 <Josh_Soref> ... either out of band, or rechartering
15:34:06 <Josh_Soref> ... there are risks to not changing now
15:34:08 <Josh_Soref> q?
15:34:11 <Josh_Soref> ack jib
15:34:16 <Josh_Soref> jib: i'm a huge fan of this pattern
15:34:20 <Josh_Soref> ... i only learned about it a few days ago
15:34:28 <Josh_Soref> ... i heard people saying "the ship is already sailed"
15:34:36 <Josh_Soref> ... this is still rather new in a lot of people's minds
15:34:41 <slightlyoff> jib: yes, it's incredibly common in JS libraries. WinJS, Q, Dojo, JQuery, etc.
15:34:43 <Josh_Soref> ... a year or so, if it's as great as you say, and i believe you
15:34:46 <slightlyoff> jib: they all have some version of it
15:34:50 <Josh_Soref> ... i don't see the argument on v1
15:34:59 <Josh_Soref> ... how are we different than other APIs that have to catch up to Futures
15:35:06 <Josh_Soref> ... WebRTC risks -- there's a performance issue
15:35:20 <Josh_Soref> slightlyoff: if there's a specific performance issue, i'll address it
15:35:27 <Josh_Soref> jib: you said you can do this in a backwards compatible way
15:35:34 <Josh_Soref> ... none of the apis return non-void today
15:35:47 <Josh_Soref> ... seems like a transition avaiable
15:36:00 <Josh_Soref> ... we could in the future make the callbacks optional, and when they're not provided, it returns a Future
15:36:12 <Josh_Soref> slightlyoff: changing your return type on variadic arguments is a huge antipattern
15:36:20 <Josh_Soref> ... either you return Promises at every point, or not at all
15:36:26 <Josh_Soref> ... to maintain a semblance of sanity
15:36:34 <Josh_Soref> ... you could not do Promises now and do them in the future
15:36:40 <Josh_Soref> ... but the risk is slight in either case
15:36:49 <Josh_Soref> ... the baggage you have today is light
15:37:08 <Josh_Soref> ... you can take the arguments as if they've been added to the Future
15:37:14 <Josh_Soref> ... i think that's an easy way to do it
15:37:25 <Josh_Soref> ... i don't think the group will have an easy way to consider things
15:37:34 <Josh_Soref> ekr: that's the v2 concept
15:37:39 <Josh_Soref> ... there will be updates to this API in the future
15:37:43 <Josh_Soref> ... introducing Futures in the future
15:37:44 <ekr> Josh_Soref: that was juberti, not me.
15:37:50 <Josh_Soref> s/ekr/juberti/
15:38:00 <Josh_Soref> ... this sort of backwards compat shimming is the only way i can see to do it
15:38:16 <Josh_Soref> annevk: it seems like a bad idea to double the legacy function space
15:38:21 <Josh_Soref> ... if we should do this, we should do it
15:38:28 <Josh_Soref> ... these decisions make the platform bloated
15:38:36 <Josh_Soref> ... the long term cost is high
15:38:43 <Josh_Soref> juberti: saying a flag day is coming
15:38:49 <Josh_Soref> ... people will miss the message and be angry
15:38:56 <Josh_Soref> ... that you can't get your stuff together
15:39:03 <Josh_Soref> ... the only way i'm compatible is some transition
15:39:17 <Josh_Soref> ... saying all of a sudden passing the callbacks doesn't work anymore
15:39:21 <Josh_Soref> ... you have to shift over to future
15:39:37 <Josh_Soref> slightlyoff: for experimental apis, it's a fine thing to do
15:39:44 <Josh_Soref> ... we're not really shipping it on stable anyway
15:39:46 <stefanh> q?
15:39:58 <Josh_Soref> jesup: Chrome is shipping it on stable
15:40:05 <Josh_Soref> ... and Firefox will be shipping it on stable
15:40:08 <Josh_Soref> q=Josh_Soref
15:40:14 <Josh_Soref> queue=Josh_Soref
15:40:16 <adambe> q?
15:40:19 <Josh_Soref> Zakim, mute dom
15:40:20 <Zakim> dom should now be muted
15:40:23 <Josh_Soref> Zakim, unmut me
15:40:23 <Zakim> I don't understand 'unmut me', Josh_Soref
15:40:24 <Josh_Soref> Zakim, unmute me
15:40:24 <Zakim> Josh_Soref should no longer be muted
15:40:44 <Josh_Soref> s/slightlyoff/annevk/
15:40:51 <Josh_Soref> queue=dom, ekr
15:41:00 <Josh_Soref> Zakim, mute me
15:41:00 <Zakim> Josh_Soref should now be muted
15:41:03 <Josh_Soref> Zakim, ack dom
15:41:03 <Zakim> unmuting dom
15:41:04 <Zakim> I see ekr on the speaker queue
15:41:20 <Josh_Soref> dom: we've been talking about APIs that are indeed shipping
15:41:28 <Josh_Soref> ... it's reasonable to debate on moving for shipping
15:41:33 <Josh_Soref> ... but for non shipping
15:41:40 <Josh_Soref> ... we should consider
15:41:45 <Josh_Soref> ... for WebRTC, we have a lot of callbacks
15:41:55 <Josh_Soref> ... the benefit of moving to Futures is fairly substantial
15:42:09 <Josh_Soref> ... the benefit is fairly strong
15:42:14 <Josh_Soref> ... adding new stuff doesn't really help
15:42:24 <Josh_Soref> ... the actual impact to the specification isn't that high
15:42:31 <Josh_Soref> ... the impact of scoping might not be that bad
15:42:43 <Josh_Soref> ... my current take is to go w/ a backward compatible change for v2
15:42:50 <Josh_Soref> ... there's momentum behind APIs
15:42:51 <jib> q+
15:42:58 <Josh_Soref> ... i take seriously that the future is bigger than the past
15:43:05 <Josh_Soref> ... but there aren't that many consumers today
15:43:09 <Josh_Soref> ack ekr
15:43:25 <Josh_Soref> ekr: there's an implicit assumption in the argument that annevk and slightlyoff are making
15:43:38 <Josh_Soref> ... that in 2 years, we're going to miss the existence of Futures
15:43:46 <Josh_Soref> ... i understand all these JS libraries have futures
15:43:55 <Josh_Soref> ... but it isn't the same that every platform will have Futures
15:44:02 <jesup> q+
15:44:06 <Josh_Soref> ... but in 2 years, we could be upset that we have Futures
15:44:11 <Josh_Soref> ... it's probable that we'll wish we hadn't
15:44:21 <Josh_Soref> annevk: ekr, you work for Mozilla?
15:44:33 <Josh_Soref> ... have you looked at the Firefox OS APIs?
15:44:41 <Josh_Soref> ... for Firefox OS, we use a pattern very similar to Futures
15:44:44 <Josh_Soref> ... we call it DOM Request
15:44:56 <Josh_Soref> ... Mozilla as an organization has already embraced it for a while
15:45:03 <Josh_Soref> ... it is our plan to use it for all APIs
15:45:11 <Josh_Soref> ekr: nobody had heard of Firefox OS 2 years ago
15:45:23 <Josh_Soref> ... you're talking about a 180 that's two years old
15:45:29 <Josh_Soref> ... but there could be more 180s in two years
15:45:39 <Josh_Soref> ... this opinion about engineering paradigms changes very rapidly
15:45:49 <Josh_Soref> ... i don't think you've offered a convincing argument
15:45:58 <Josh_Soref> annevk: i'm not willing to put your users in the line of fire
15:46:04 <Josh_Soref> ... this isn't about your specific API
15:46:09 <Josh_Soref> s/annevk/slightlyoff/
15:46:15 <Josh_Soref> ... this is about the health of the overall platform
15:46:21 <Josh_Soref> ... it's about how usable the platform is
15:46:31 <Josh_Soref> ... how much shimming/layering/spackle needs to be applied
15:46:35 <Josh_Soref> ekr: everyone wants their think
15:46:39 <Josh_Soref> s/think/thing/
15:46:46 <Josh_Soref> slightlyoff: this is the best thing we can get away with
15:46:59 <Josh_Soref> ekr: you're taking as your premise that we'll be better off if WebRTC did futures
15:47:07 <Josh_Soref> ... if it isn't true in two years, it'll be the wrong thing
15:47:16 <Josh_Soref> slightlyoff: WebRTC will be better off even if no one else adopts them
15:47:22 <Josh_Soref> ... let me explain why
15:47:32 <Josh_Soref> ... WebRTC has at least one API that takes non optional apis
15:47:34 <Josh_Soref> ... to coordinate on that API
15:47:43 <Josh_Soref> ... you must have the pieces ready then
15:47:56 <Josh_Soref> ... it isn't possible to do this without wrapping it
15:48:05 <Josh_Soref> ... your costs blanch in comparison to shipping code down the wire
15:48:23 <Josh_Soref> ... at the same time, the overall utility of your system is increased when people don't have to reason about the time at the result
15:48:35 <Josh_Soref> ... promises let you reason about things in a way similar to events
15:48:43 <Josh_Soref> ... it's a level given to you which you don't have in the API you have
15:48:48 <Josh_Soref> ... which is given to you for free
15:49:02 <Josh_Soref> ... this is why systems like IndexedDB have invented Ad-hoc ways of doing this
15:49:11 <Josh_Soref> ... their implementation wasn't good
15:49:14 <Josh_Soref> ekr: stipulate that's true
15:49:26 <Josh_Soref> ... just because a paradigm of this general kind is preferable
15:49:32 <Josh_Soref> ... DOM Request
15:49:38 <Josh_Soref> ... if you get something like Futures but not exactly Futures
15:49:45 <Josh_Soref> annevk: we'll be much better off than what you have now
15:49:51 <Josh_Soref> ekr: we'll be incompatible in some way
15:50:00 <Josh_Soref> ... you'll have not .then() but .next()
15:50:05 <Josh_Soref> slightlyoff: this has a QQQ issue
15:50:11 <Josh_Soref> ... why bother shipping ....
15:50:15 <dom> s/QQQ/infinitely recursion/
15:50:19 <Josh_Soref> ekr: we know people actually want the thing we're trying to do
15:50:23 <Josh_Soref> annevk: the same goes for us
15:50:29 <dom> s/ly re/ re/
15:50:32 <Josh_Soref> ekr: other than you, i don't see any demand in WebRTC
15:50:34 <stefanh> q?
15:50:49 <dom> s/recursion/regression
15:50:50 <Josh_Soref> annevk: there's a lot of demand on the web for Futures
15:50:53 <slightlyoff> Josh_Soref: infinite regress
15:50:56 <Josh_Soref> ... i don't think they'll lobby each individual API
15:51:08 <Josh_Soref> ... i don't think people will read each individual API
15:51:17 <Josh_Soref> ... which is why we ended up w/ IndexedDB which is quite bad
15:51:39 <Josh_Soref> abr: i'd encourage you to look
15:51:46 <Josh_Soref> q+ burn
15:51:50 <annevk> s/abr:/alex:/
15:51:57 <Josh_Soref> s/alex:/slightlyoff:/
15:52:01 <Josh_Soref> q?
15:52:04 <Josh_Soref> ack jib
15:52:10 <Josh_Soref> jib: i'm more optimistic than ekr
15:52:18 <Josh_Soref> ... but i can say this is "a great api"
15:52:22 <Josh_Soref> ... but the timing is lousy
15:52:28 <Josh_Soref> ... if you had a year ago, great
15:52:35 <Josh_Soref> ... but i don't think we'll delay Firefox to cram this in now
15:52:41 <Josh_Soref> ... question to Chrome/Firefox
15:52:46 <Josh_Soref> ... for some things we're still Prefixed
15:53:00 <Josh_Soref> ... when we remove Prefixes in the future, is that an opportunity in the future?
15:53:11 <Josh_Soref> annevk: i was under the impression we'd ship it unprefixed on stable
15:53:19 <Josh_Soref> ... but i don't think we should ship unprefixed apis on stable
15:53:27 <Josh_Soref> qqq: i don't know what to make of this
15:53:33 <Josh_Soref> ... we've shipped tons of unprefixed things on stable
15:53:36 <Josh_Soref> ack jesup
15:53:36 <dom> s/qqq:/juberti:/
15:53:53 <Josh_Soref> jesup: on prefixed apis, there's been a discussion in Mozilla
15:54:04 <Josh_Soref> ... on moving away from prefixed
15:54:09 <Josh_Soref> ... one was WebRTC the other WebGL
15:54:14 <Josh_Soref> ... no plans to change that for
15:54:20 <Josh_Soref> ... this year
15:54:29 <Josh_Soref> ... that gives us an entry to change later
15:54:43 <Josh_Soref> ... there was an argument about being terribly sorry about callback v. Futures
15:54:55 <Josh_Soref> ... a horrible cost of downloading the bits of a polyfill
15:55:03 <Josh_Soref> ... that seems like an awfully large stretch for me
15:55:10 <Josh_Soref> ... unless the polyfill for implementing Futures is huge
15:55:14 <Josh_Soref> ... and i don't think it is
15:55:22 <Josh_Soref> slightlyoff: everything over cost and materials is expensive
15:55:26 <Josh_Soref> ... relative to you
15:55:32 <Josh_Soref> ... you can choose which is free and which costs a lot
15:55:33 <adam> q+
15:55:37 <Josh_Soref> jesup: i understand that
15:55:41 <Josh_Soref> ... there are relative costs
15:55:46 <Josh_Soref> ... you have to weigh them
15:55:46 <Cow_woC> Futures.js is 10k unminimized/uncompressed.
15:56:00 <Josh_Soref> ... the balance of this argument would be different if it was 6 months ago
15:56:04 <Cow_woC> The cost/benefit is great in my opinion.
15:56:06 <Josh_Soref> annevk: consider the maintenance cost
15:56:20 <Josh_Soref> ... while also expanding the API going forward
15:56:32 <Josh_Soref> ... overloading everything w/ two versions isn't great
15:56:38 <Josh_Soref> jesup: i don't see that cost as problematic
15:56:40 <Josh_Soref> ack burn
15:56:46 <Josh_Soref> burn: i was going to remind people
15:56:51 <Josh_Soref> ... that the discussion is what we should standardize
15:57:00 <Josh_Soref> ... not about "is futures a good paradigm"
15:57:07 <Josh_Soref> ... it's understood that anyone could learn it
15:57:11 <Josh_Soref> ... we could add futures in the future
15:57:16 <Josh_Soref> ... it's about "do we standardize it now"
15:57:28 <Josh_Soref> ... i wanted to stop the "are futures a better model" argument
15:57:31 <Josh_Soref> ack adam
15:57:40 <Josh_Soref> adam: what burn said is a good leadin to what i wanted to say
15:57:40 <ekr> burn: but the question of whether it's a better programming paradigm goes to the question about whether this change is even desirable
15:57:46 <Josh_Soref> ... the risk i see
15:57:55 <Josh_Soref> ... is there isn't any current w3 work on Futures
15:58:03 <Josh_Soref> ... we're standing behind a spec that w3 hasn't started on
15:58:08 <Josh_Soref> ... to get WebRTC fiinished
15:58:23 <Josh_Soref> annevk: this has been discussed to great extent on w3 lists
15:58:32 <Josh_Soref> ... w3 doesn't have a person to copy spec text
15:58:43 <Josh_Soref> slightlyoff: there are w3 specs that have decided to buy off on w3 specs
15:58:44 <Cow_woC> Migrating to Futures is like adding exception handling to an API that previously only used simple return types. Sure you can wrap it, add it later, etc... but it's a fundamental API change and has a huge potential benefit if applied at the source.
15:58:47 <Josh_Soref> ... WebCrypto is on the hook
15:58:57 <Josh_Soref> ... the next draft of their spec will be based on Promises/Futures
15:59:02 <ekr> q+
15:59:06 <Josh_Soref> ... i'm working w/ their spec author to make it part of their api
15:59:20 <Josh_Soref> ... that Futures hasn't transferred to the W3 spec land
15:59:32 <Josh_Soref> zz: i suspect it may be more than an organizational issue
15:59:42 <Josh_Soref> slightlyoff: TAG agreed at the last meeting
15:59:46 <Josh_Soref> ... and tbl was excited
15:59:49 <Josh_Soref> s/zz/burn/
15:59:50 <dom> s/zz/burn/
16:00:04 <Josh_Soref> stefanh: the WebRTC and MC TF doesn't seem convinced
16:00:18 <Josh_Soref> ... we could move MediaStream Recording and Image Capture to Futures
16:00:24 <Josh_Soref> q?
16:00:29 <ekr> q-
16:00:36 <Josh_Soref> ... any final comments?
16:00:45 <Josh_Soref> dom: non shipping apis?
16:00:57 <gmandyam> +q
16:01:10 <Josh_Soref> stefanh: personal feeling is that we should really consider moving them
16:01:15 <Josh_Soref> ack gmandyam
16:01:25 <Josh_Soref> gmandyam: provide a polyfill and let people experiment with this stuff
16:01:33 <Josh_Soref> ... and then later we can have a better experience
16:01:43 <Josh_Soref> ... we can take a more nuanced view at that time
16:01:47 <dom> s/gmandyam/juberti/
16:01:50 <Josh_Soref> slightlyoff: that doesn't wash w/ spec process
16:01:59 <gmandyam> That is definitely not me - it is Justin I believe
16:02:03 <Josh_Soref> ... you can't do that
16:02:14 <Josh_Soref> ... you're interleaving timing about a v1 api
16:02:20 <Josh_Soref> ... w/ potential for changes for a v2
16:02:23 <Zakim> - +972.9.957.aagg
16:02:25 <Josh_Soref> ... but i don't know about your schedule
16:02:30 <Josh_Soref> ... everyone wants to ship something standardized
16:02:37 <Josh_Soref> juberti: i'm suggesting leaving apis as they are
16:02:43 <Josh_Soref> ... XHR doesn't use Futures
16:02:47 <Josh_Soref> slightlyoff: we have a plan for fixing them too
16:02:56 <Josh_Soref> juberti: it won't happen overnight
16:03:05 <Josh_Soref> slightlyoff: we're talking with you because it's the best to fix your future legacy
16:03:21 <Josh_Soref> juberti: i'm offering a pragmatic path
16:03:31 <Josh_Soref> annevk: it sounds like you're offering "fuck off"
16:03:43 <Josh_Soref> ppp: we have a polyfill
16:03:50 <Josh_Soref> stefanh: i'm sure we will return to this topic
16:03:54 <dom> s/ppp/annevk/
16:04:02 <annevk> that was alex
16:04:05 <Josh_Soref> Josh_Soref: i don't want to scribe this same meeting in June 2014
16:04:07 <annevk> fuck off was me
16:04:09 <Zakim> -ekr
16:04:13 <Zakim> -dom
16:04:17 <Zakim> -fjh
16:04:19 <Zakim> -annevk
16:04:19 <Zakim> -stefanh
16:04:20 <Zakim> -jib
16:04:21 <Zakim> -gmandyam
16:04:22 <Zakim> -Jim_Barnett
16:04:22 <Zakim> -adambe
16:04:23 <Zakim> -jesup
16:04:24 <Zakim> -Dini_Martini
16:04:29 <Zakim> -Josh_Soref
16:04:31 <Zakim> - +1.425.936.aaff
16:04:32 <Zakim> -Dan_Burnett
16:04:36 <dom> s/annevk: we/slightlyoff: we/
16:04:45 <Josh_Soref> trackbot, end meeting
16:04:45 <trackbot> Zakim, list attendees
16:04:45 <Zakim> As of this point the attendees have been +30210818aaaa, +91.22.39.14.aabb, fjh, stefanh, Josh_Soref, dom, adam, Jim_Barnett, annevk, gmandyam, Alex, +46.1.07.14.aacc, jib, adambe,
16:04:48 <Zakim> ... Dini_Martini, ekr, +44.207.346.aadd, +1.610.889.aaee, jesup, Dan_Burnett, +1.425.936.aaff, +972.9.957.aagg
16:04:51 <Cow_woC> Lovely
16:04:53 <trackbot> RRSAgent, please draft minutes
16:04:53 <RRSAgent> I have made the request to generate http://www.w3.org/2013/06/05-mediacap-minutes.html trackbot
16:04:54 <trackbot> RRSAgent, bye
16:04:54 <RRSAgent> I see no action items
16:04:54 <Zakim> -adam