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

On Wed, Jun 12, 2013 at 5:00 PM, Stefan Håkansson LK <
stefan.lk.hakansson@ericsson.com> wrote:

> On 6/12/13 5:25 PM, Alex Russell wrote:
> > Sorry for the slow response. Inline:
>
> No problem! Some responses inline below.
>
> >
> >
> > On Sat, Jun 8, 2013 at 3:54 PM, Stefan Håkansson LK
> > <stefan.lk.hakansson@ericsson.com
> > <mailto: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>
> >      > <mailto: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.
>
> For me it is a problem if there is no owner for the spec right now. I
> think there should be a W3C document describing Promises the Media
> Capture/WebRTC references.
>

I'll leave that question for Anne to address.


> And I assume that pushing this through the W3C process could mean changes.


I don't think so. It's a small contract, and we've bike-shedded it to death
in the CSS and public-script-coord threads as well as a pre-standards
debate that was months-long with the various people who are stakeholders in
the Promises community. It will be this particular pantone version of this
particular color forever.

CC-ing some folks who can give you more insight into that statement.

>
> >     - 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?
>
> Maybe we're speaking past each other, but should not Promises be
> documented in a W3C document (and I assumed in the DOM spec)?


It's not clear it matters. If it does, we can do the same copy/paste from a
WHATWG spec that other W3C specs routinely do.


> >      >     (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 agree to this - there is no inbuilt conflict between capable and
> natural. But let me put it this way instead: I would say that the focus
> of the work so far has been more on making sure that the API is capable,
> and less on ease to use.
>

That's fine. I hope you'll also feel that your API is not 1.0-ready until
the sharp edges have been polished off, though. I can't agree that the
current focus has delivered the hoped-for product, only a capable one.


> And my (and many other's) assumption has been that Futures/Promises
> would have to go through a W3C process to become a standard, and in that
> process we would likely see changes, and we (Media Capture/WebRTC)
> should focus on other stuff until Futures/Promises have advanced a bit
> in the W3C process.
>
> >
> >     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.
>
> Sounds great!


Great! Would really enjoy that.


> >     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
> >      >
> >      >
> >
> >
>
>