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

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.

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

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

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

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!

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

Received on Wednesday, 12 June 2013 16:01:03 UTC