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