4 ms·
Wasi co-chair and Wasmtime maintainer here: we agree! Wasi Preview 1, which this article is about, was a first attempt at porting some of these Unix ideas to Wa
by phickey 3y ago
Wasi co-chair and Wasmtime maintainer here: we agree! Wasi Preview 1, which this article is about, was a first attempt at porting some of these Unix ideas to Wasm. We found pretty quickly that unix isn't the right abstraction for Wasm. Not only is it not really portable to platforms like Windows without reinventing a compatibility layer like cygwin, it also doesn't really make sense in a Web embedding, where users end up implementing something like a unix kernel in Javascript.
Wasi Preview 2, which we are aiming to launch by the end of the year, rebases Wasi on the Component Model proposal, which enables composition of Wasm programs, including those which are written in different languages, and which do not trust each other. Wasi is now specified in the Wit IDL, which has a strong type system for representing records, variants, lists, strings, and best of all, external resources, including sugar for constructors, methods, and destructors.
Instead of basing everything on the filesystem abstraction, the core Wasi primitives are the `input-stream`, `output-stream`, and `pollable` resource types, for readable and writable bytestreams, and a pseudo-future: you can `poll-oneoff` on a `list<pollable>` and it will block until one is ready, and return a `list<bool>` indicating the set which are ready. `wasi:filesystem/types.{descriptor}` is the resource for files, but if you need to read, write, or append to a file, you can do so by calling a method on `descriptor` that returns a `input-stream` or `output-stream`.
Preview 2 is also adding networking: wasi-sockets for platforms which support sockets, and wasi-http for those which don't, like the Web.
We are closing in on shipping Wasi Preview 2 but its not quite fully baked yet - changes related to resources are slated to land in the net few weeks. The spec definitions are on github: https://github.com/WebAssembly/wasi-io/blob/main/wit/streams.wit https://github.com/WebAssembly/wasi-io/blob/main/wit/streams... https://github.com/WebAssembly/wasi-filesystem/blob/main/wit/types.wit https://github.com/WebAssembly/wasi-filesystem/blob/main/wit... . Stay tuned for much more approachable documentation, tutorials, and so on, once we are confident it is a stable target ready for users.
- actionfromafar 3y agoThe network really is the computer, this time!
- fassssst 3y agoNothing like reinventing COM :)
- mananaysiempre 3y ago“COM but you can actually implement it from the docs” is surprisingly compelling, honestly. There is just an absurd number of obscure corners in the original, from DCE RPC all the way to the highest levels (although those are not the only source of COM grief—IDispatch is an abomination; IStream is needlessly annoying; IMarshal is awful to use but at the same time I don’t think actually has a convincing equivalent elsewhere; etc.).
- marcus_holmes 3y agoAh, the pain of getting a DCOM connection working shudder COM was pretty reliable. Yes, it was needlessly annoying and gave CS folk the screaming ab-dabs, but it worked and was predictable. I can see COM-in-WASM being really useful. Especially if we can dynamically load components. And not only for browser coding.
- lukeh 3y agoStreams sounds more like DrawBridge!
- bsder 3y agoNobody has a good IPC/RPC-based abstraction set right now. And everybody is kind of struggling with that. Look at the latest Microsoft thing about embedding Python in Excel. They're going the wrong direction. What everybody wants is to be able to drive Excel from Python aka an API that people could hook into. Even WASM is kind of ... weak ... because it has to deal with the lowest common denominator--a web page with a single thread of execution and no access to anything. And, COM wasn't terrible--it's just that the languages attempting to support it were very underpowered at the time. COM with VB6 created a huge ecosystem that probably still isn't really matched today.
- fassssst 3y ago
- ori_b 3y agoHave you looked at capabilities, like E, Mont-E and its descendants? https://en.wikipedia.org/wiki/Object-capability_model https://en.wikipedia.org/wiki/Object-capability_model https://monte.readthedocs.io/en/latest/taste.html#cooperation-without-vulerability https://monte.readthedocs.io/en/latest/taste.html#cooperatio... https://en.wikipedia.org/wiki/E_(programming_language) https://en.wikipedia.org/wiki/E_(programming_language)
- phickey 3y agoYes, CM resources are unforgable references.
- j-james 3y agoHmm, a strong type system? Is there any overlap between the Wit IDL and other similar projects like crABI?
- noelwelsh 3y agoVery glad to see this. It's a much better solution that The Unix Philosophy (TM) of sending around unstructured bytes.