Re: To WASM or not to WASM (Re: Raw data API - 6 - Encoders/decoders)

I think that the root of our concerns were some initial proposals/ideas 
of only allowing raw methods, leaving some parts of the implementation 
up to js libs.
This would lead to incompatibilities on the wire protocols (with for 
example libs replacing the standard rtx/fec mechanism with custom 
methods) that will disrupt current ecosystem.

Now we are talking about providing the full pipeline with 
source-shinks/streams apis, this will ensure standard compatibility 
outside of the box, so allowing raw methods on js (to some extend) 
doesn't seem so much of a problem.

So, in my opinion, it is not so much about wasm or not to wasm, but to 
custom-rtp breaking compatibility or not.

Best regards
Sergio

On 15/06/2018 8:55, Harald Alvestrand wrote:
> On 06/14/2018 10:55 AM, Lorenzo Miniero wrote:
>> -1 on an RTP stack in JS :-P
>>
>> I'm strongly against all this wasm nonsense. Just because machines are
>> getting more powerful, doesn't mean we should drop more efficient code
>> for something that runs worse just because it's easier to move around.
>> It's a trend that is happening everywhere, and I hate it, because it
>> shows no regard for those who still ship machines that would atthe very
>> least struggle with that. Besides, this seems to bring us back to the
>> "WebRTC just for browsers" era: WebRTC is everywhere, now, and I can
>> already picture my mobile phone melting down any time I open a web page
>> with WebRTC on it.
> Changing the subject again, since this is a different thread.
>
> Components in WASM are a very different beast, operations-wise than
> browser-built-in components.
>
> Browser-built-in components are under the control of the browser vendor,
> and updated on the browser release cycle - in Chrome, that currently
> means roughly 12 weeks from code to full deployment, and iterations no
> faster than on a 6-week cycle. Other browsers have different cycles.
> Each iteration affects billions of people (NOT an exaggeration), and has
> some degree of gurantees of interoperability with multiple applications.
>
> Components in WASM are under the control of the Web page provider. Their
> release cycle is totally under Web page control, changing them affects
> only the users of that particular application (and the users the
> application communicates with), and interoperability is only a concern
> for the particular set of endpoints that this application communicates with.
>
> What this means is that when we offer APIs that allow the application to
> replace a particular built-in component with a WASM alternative, the
> point isn't to reimplement what the built-in component does - it's to
> allow the application to do something *different*, under *their*
> control, not the browser's.
>
> WASM has some advantages over Javascript (simpler programming model,
> ability to use more traditional programming languages, implicit
> obfuscation of source because languages are compiled) and some
> disadvantages (no direct access to JS APIs). But the deployment paradigm
> of WASM modules is much closer to that of Web pages and JS libraries
> than it is to browser functions.
>
> Harald
>
>
>
>
>

Received on Friday, 15 June 2018 08:08:16 UTC