Re: [Promises/Futures] Media Capture Task Force call

Sorry for the slow response. Inline:


On Sat, Jun 8, 2013 at 3:54 PM, Stefan Håkansson LK <
stefan.lk.hakansson@ericsson.com> wrote:

> On 6/6/13 5:45 PM, Alex Russell wrote:
> > Hi Stefan,
> >
> > Thanks for taking the time to reply.
> >
> > On Wed, Jun 5, 2013 at 6:19 PM, Stefan Håkansson LK
> > <stefan.lk.hakansson@ericsson.com
> > <mailto:stefan.lk.hakansson@ericsson.com>> wrote:
> >
> >     On 6/5/13 6:48 PM, Alex Russell wrote:
> >      > Hey all,
> >      >
> >      > As part of our agreed work to help coordinate with WG's about
> >      > idiomaticness and cleanliness of APIs, Anne and I joined the Media
> >      > Capture group for a call today to discuss the adoption of
> >      > Promises/Futures in their API. The minutes are here:
> >
> >     Thanks for joining!
> >
> >
> > Thanks for having us. I know it was a loaded topic and I appreciate
> > everyone taking the time, if only to acquaint us with the various
> > positions and constraints.
> >
> >      > http://www.w3.org/2013/06/05-mediacap-minutes.html
> >      >
> >      > I don't think it's stretching the case to say that the reception
> was
> >      > something close to hostile, if not outright incredulous.
> >
> >     I agree to that people did not exactly embrace Futures. I think it
> shall
> >     be seen in light of that the WebRTC is really complex. In addition to
> >     discussing the API design in W3C space, there is a huge controversy
> in
> >     the IETF - involving about four separate WGs - on signaling and
> >     protocols for setting up the real-time media and data over the
> network.
> >
> >
> > I see. I should note for whatever record there might be that I'm hugely
> > grateful that WebRTC is happening and for the work that your group has
> > put into enabling this capability in the web. Efforts like WebRTC and
> > Media Capture are one of the reasons I have hope that our platform can
> > compete.
> >
> >     I think many are simply exhausted by discussing so many different
> topics
> >     in different groups, so they want to minimize changes wherever they
> can.
> >
> >
> > I can understand and appreciate that exhaustion.
> >
> > Everyone would prefer if the platform had grown a Promises contract
> > about the same time it introduced XHR, but that water is under this
> > bridge and now all we can do is set about doing the best we can...and
> > that will mean many changes across many APIs to (finally!) present a
> > unified front. If WebRTC/Capture can't make the change now, there will
> > be future opportunities to do so in the future. We only hoped to engage
> > in an attempt to save you the legacy burden.
>
> Yes, and it is good that you do that. I think you put a seed in the mind
> of many at the call. The result will quite likely be that for now WebRTC
> continues with the current design, but everyone has an eye on the
> development of Promises, and the final outcome is not clear yet.
>

Glad to hear that. It sounds like the CSS WG is looking at them for an API
now as well, and we've resolved what I think is the final (small)
controversy there.


> I personally share the WG's view that at least for the WebRTC 1.0
> document the WG should for now continue with the current callbacks.
>

And the path we proposed doesn't require you to abandon that to adopt
 Promises. It's good if you can, but compatible if you don't.


> There is too much other stuff going on, and Promises is not exactly at
> LC yet


There's no owner for the DOM spec right now, so it's not clear what that
statement is meant to imply. Practically speaking, both Chrome and FF are
implementing now and the design is done.


> - there could be changes as Promises go on in the W3C process and
> having to follow that would be yet another thing for the WG. But if
> Promises stabilize in the no too distant future we could revisit.


I'd like to understand what you think that means. In particular, what
"stabilized" would look like given the current DOM WG. It's a core type
that's being included broadly in new APIs. None of the recent changes would
have had observable effects for users of your API. What more are you
looking for?


> >     (Regretfully there was also some arguing that Futures might be in
> >     fashion now but soon forgotten - I think that was beside the point.)
> >
> >
> > I'm afraid that argument -- which strikes me mostly to be from an
> > ignorance of common JS library patterns and idioms -- indicates a major
> > blind spot for this WG. Not understanding that everything from WinJS to
> > JQuery rely on a Promises (and promise-like abstractions) says more
> > about the WG's current participants than it does about Promises and
> > their popularity (or faddishness).
> >
> > Honestly, this argument makes me want to suggest that other TAG members
> > should start immediately looking at WebRTC/Capture APIs for other
> > idiomaticness issues as the WG doesn't seem equipped for the task as
> > currently constituted.
> >
> > What do you think the right way would be for us to provide that sort of
> > feedback in?
>
> I think you're right in that the weight of the TF/WG lies with RTC
> experts (people who are really good at protocols like RTP, with jitter
> handling, codecs, and so one) and that there are not that many with a
> Web background. Naturally that influences the designs we're making.
>
> Personally I have from time to time argued for simplifications, and I
> think that some things could be made simpler to use - but it is also
> easy to lose functionality if you simplify. From another perspective,
> perhaps our platform is better off with a harder to use, but more
> capable API than the other way around?
>

This is a false dichotomy, as presented.

It's possible for an API to be powerful and complicated but still be
idiomatic. An API can be low-level (requiring lots of effort to accomplish
things) but still be naturally expressable and usable in your source
programming language.

The move from ad-hoc callbacks to Promises changes your semantics not at
all (AFAICT), but makes it easier to use. You might therefore call this
"cosmetic", but in aggregate, cosmetic changes add up to a trustable,
reliable surface area that has a uniform charachter and flavor or a
hodge-podge of useful-but-ugly oneoffs that paint no coherent picture when
zoomed out.


> I think a good starting point would be to comment, on the list, the
> document "Media Capture and Streams". It is the one closest to a LC, and
> I hope it is reasonable from an web API perspective - but feedback and
> comments are most welcome and would be helpful.
>

I will. Additionally, I'll be asking that you participate in a future TAG
meeting and present your API in detail for review.


> As for the "WebRTC 1.0" document, that API is much more complex to use.
> Part of the complexity probably comes mistakes on our side (we could
> have found more clever ways to interface to the underlying solutions),
> but it is also a result from combining a lot of complex technologies
> together, and enabling the application to use those technologies in a
> way that enables good services to be built. This document is also
> further away from a last call, so perhaps it can be looked into later.
>

For the record, I'm *all for *adding power to the platform. My comments are
constrained to the form that power takes, and not a discussion of the
layering. Low-level stuff naturally takes work to form into something that
does a higher-level job; and it's great that we're getting these primitives
into the platform. My concern, once we've agreed to do it, is that we do it
well.


> Well, those were my thoughts, I don't know what Dom and Harald thinks.
>
>
> >
> >     And I think almost no-one ruled out Futures, people more said "let us
> >     wait and see for a bit".
> >
> >
> > Which is good!
> >
> >      > Unlike some other groups which I've had the pleasure to work with,
> >      > participants here seem to be worried that a relatively minor
> >     change (and
> >      > a backward compatible one) is a major compatibility risk.
> >      >
> >      > Perhaps further discussion of the acceptance of Promises across
> >     the W3C
> >      > might ease their minds, and I was hoping those here with more
> >     experience
> >      > might be able to guide the discussion to a less contentious
> >     conclusion.
> >      >
> >      > Regards
> >
> >
>
>