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

On Fri, Jun 15, 2018 at 8:09 AM Sergio Garcia Murillo <
sergio.garcia.murillo@gmail.com> wrote:

> 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.
>
>
I'm persuaded by "default components" for the sake of making simple things
simple, but I'm not at all persuaded by the compatibility argument.  If
someone wants to make custom RTP payloads/packetizations or use SCTP
instead of RTP, let them.


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