undefined | Better HN

0 pointsapitman1y ago0 comments

I agree that some things are essential, and there's value in specifications. The question is how likely is the current tragectory to follow what happened with browsers? The major players are the same, which is concerning. Then there's early signs from the specs themselves. Why do we need wasi-sockets and wasi-http? Why not only specify wasi-sockets and let HTTP be implemented optionally by libraries for apps that need it?

Are there any forces in place to prevent the (de facto) mandatory API from becoming so complex that Google (or Fastly) is the only org capable of maintaining an implementation? Because that's how you end up in the situation where the "user agent" with majority market share starts gutting ad blockers.

I'm not saying I'm predicating this will happen with WASM or even think it's very likely. I don't know enough to have a real opinion on that. I'm just saying I really really don't want it to happen.

0 comments

yoshuaw1y ago

> Are there any forces in place to prevent the (de facto) mandatory API from becoming so complex that Google (or Fastly) is the only org capable of maintaining an implementation?

The big change going from WASI 0.1 to WASI 0.2 is that we decoupled the calling convention (Wasm Components) from the actual syscall APIs (WASI). That enabled us to make the various syscall APIs modular and composable.

Because CDN functions probably shouldn't know about TCP; and CLI applications probably don't care about blob storage. And now they don't need to. Take a look at the WASI Proposals page [1] for an overview of all WASI APIs.

[1]: https://github.com/WebAssembly/WASI/blob/main/Proposals.md

apitmanOP1y ago

So basically the reasoning is that things like wasi-http wouldn't be mandatory for a compliant implementation? That would be good.

Thanks for the link. I was trying to find a single page with everything listed.

coldtea1y ago

>The question is how likely is the current tragectory to follow what happened with browsers?

What happened to browsers? Few vendors implementing them? There are still 3 major vendors supporting an open source runtime or two (Google and MS on Blink), and a good open implementation (Mozilla). Better than 20 competing engines, does anybody miss IE's own engine?

And with WASM it's way easier for multiple implementations to be written, if need be, as it's a language runtime. These have 1/100th the scope of a browser (which is 99 other very hard to implement things PLUS a WASM runtime).

>The major players are the same, which is concerning. Then there's early signs from the specs themselves. Why do we need wasi-sockets and wasi-http? Why not only specify wasi-sockets and let HTTP be implemented optionally by libraries for apps that need it?

Because "let third parties define and write basic libraries" (and sockets and http are very basic) has been a disaster every time. You get a fragmented ecosystem, several popular libs fighting it out, and users either stay away or suffer the consequences.

At least with an official spec implementations will be compatible, and we'll get some reference one.

panick21_0y ago

I think it makes a lot of sense to have a standard HTTP interface. I mean, HTTP is well defined and the interface matches the spec pretty closely. Allowing implementers to use whatever underlying protocols is sensible, specially in cloud environments.

You can also have a standard web assembly component that simply implements wasi-http on top of wasi-sockets.

j / k navigate · click thread line to collapse