See also: IRC log
<trackbot> Date: 05 June 2013
<scribe> scribe: Josh_Soref
<stefanh> propsed agenda: http://lists.w3.org/Archives/Public/public-media-capture/2013Jun/0009.html
<annevk> Zakim: I know!
<jib> I'm calling from skype
<annevk> Josh_Soref: Dini_Martini
stefanh: i posted the agenda earlier
<Cow_woC> Hi guys :)
<slightlyoff> howdy all
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
<jesup> zakim: aaee is me
annevk: 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 XXX
... 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
<slightlyoff> Josh_Soref: a divergence in syntactic patter, you see differences in semantics -- however we see wide divergence in syntax too!
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
<slightlyoff> Josh_Soref: was slightlyoff
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
ekr: that's the v2 concept
... there will be updates to this API in the future
... introducing Futures in the future
<juberti> Josh_Soref: that was juberti, not me.
ekr: 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
<slightlyoff> Josh_Soref: infinite regress
annevk: 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
<Cow_woC> Futures.js is 10k unminimized/uncompressed.
jesup: the balance of this argument would be different if it was 6 months ago
<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
<dom> s/zz/burn/
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?
<gmandyam> +q
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
<gmandyam> That is definitely not me - it is Justin I believe
slightlyoff: 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
<annevk> that was alex
Josh_Soref: i don't want to scribe this same meeting in June 2014
<annevk> fuck off was me
trackbot, end meeting
<Cow_woC> Lovely
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/jib was speaking// Succeeded: s/annevk/slightlyoff/ Succeeded: s/annevk: not sure/slightlyoff: not sure/ Succeeded: s/failures/failure/ Succeeded: s/WG/TF/ Succeeded: s/Platform/Fashion/ Succeeded: s/ekr/juberti/ Succeeded: s/slightlyoff/annevk/ Succeeded: s/annevk/slightlyoff/ Succeeded: s/think/thing/ Succeeded: s/QQQ/infinitely recursion/ Succeeded: s/ly re/ re/ Succeeded: s/recursion/regression/ Succeeded: s/abr:/alex:/ Succeeded: s/alex:/slightlyoff:/ Succeeded: s/qqq:/juberti:/ Succeeded: s/zz/burn/ FAILED: s/zz/burn/ Succeeded: s/gmandyam/juberti/ Succeeded: s/ppp/annevk/ Succeeded: s/annevk: we/slightlyoff: we/ Found Scribe: Josh_Soref Inferring ScribeNick: Josh_Soref Default Present: +30210818aaaa, +91.22.39.14.aabb, fjh, stefanh, Josh_Soref, dom, adam, Jim_Barnett, annevk, gmandyam, Alex, +46.1.07.14.aacc, jib, adambe, Dini_Martini, ekr, +44.207.346.aadd, +1.610.889.aaee, jesup, Dan_Burnett, +1.425.936.aaff, +972.9.957.aagg Present: +30210818aaaa +91.22.39.14.aabb fjh stefanh Josh_Soref dom adam Jim_Barnett annevk gmandyam Alex +46.1.07.14.aacc jib adambe Dini_Martini ekr +44.207.346.aadd +1.610.889.aaee jesup Dan_Burnett +1.425.936.aaff +972.9.957.aagg Frederick_Hirsch WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 05 Jun 2013 Guessing minutes URL: http://www.w3.org/2013/06/05-mediacap-minutes.html People with action items:[End of scribe.perl diagnostic output]