find VS wasi-io

see my comment in this thread about https://github.com/internet4000/find (for a summary); (web-)apps can be encapsultated, from the URI you access them, and the code that is served by the loaded page. It could also run client side only, local first (web apps manifest, service workers, sqlite/postgres wasm etc.)

Interesting work with the representation of the Content through the URL, to allow the agent/actor to discover the information through different path.

↓

[...]

- CSS(--variable)

- DOM(attributes=value)

- FORM(input[name])

- URL(path?param#resource)

- HTTP(?params{body})

- SCRIPT(--attribute)

- DB(model?filters)

- FS(folder/filer/{content})

[...]

↑

- https://www.w3.org/OWL/ maybe to harmonize the representation/attribute/value

- https://opensearch.org/ for sharing patterns

- informal work on https://internet4000.github.io/find

There is also client side configuration possible with https://github.com/internet4000/find

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` and it will block until one is ready, and return a `list` 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`.

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