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

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.

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. 
There is too much other stuff going on, and Promises is not exactly at 
LC yet - 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.

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

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.

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.

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 Saturday, 8 June 2013 14:55:26 UTC