Re: What would you like to see in WebRTC next? A low-level API?

On Thu, Jan 25, 2018 at 1:13 AM, Philipp Hancke <fippo@goodadvice.pages.de>
wrote:

>
>
> Am 24.01.2018 um 17:33 schrieb Peter Thatcher:
> [...]
>
>> We (Chrome WebRTC implementors) get a pretty continuous stream of feedback
>> from web app developers.  And some of us (myself included) are working on
>> both WebRTC implementations and web apps.  I started this thread trying to
>> distill down a summary of what we're hearing from web app developers most
>> often: they want more direct, low-level control.
>>
>
> This doesn't match my perception of discuss-webrtc, stackoverflow or a
> bunch of github repositories. Nor what I saw here:
>     https://twitter.com/ChromiumDev/status/933022156711067649


Those sources give part of the picture, but miss the major RTC-focused
developers, who want more control (both in terms of APIs and application
deployment) and the ability to differentiate.

At this point in time, the vast majority of WebRTC usage comes from
RTC-focused developers, so it makes sense to consider how we might better
support them.



> Am I missing a place where I can learn about issues before they hit me?
>
> But I agree it would be nice to have more app developers providing direct
>> input in the WG.
>>
>> Your case of addStream vs addTrack is interesting: would you have been
>> better off if we (Chrome) had shipped ORTC (or something lower-level)
>> first
>> rather than focusing on finishing addTrack (as we are currently doing)?
>>
>
> Some of us have to support four browsers :-p
> So, without ORTC support in Firefox I would probably have applied the same
> shim as in Edge.
>
> For the same reason I shimmed addTrack for Chrome in adapter. The
> alternative would have been to either not use addTrack which would probably
> have resulted in lots of stuff breaking (cf how much effort it took to get
> the interactions between addTrack and legacy getLocalStreams() etc right)
> or to sprinkle "if (isChrome) useAddStream else useAddTrack" in even more
> places.
>
>