Currently static methods and special types of resources are fully supported. It seems like most of the relevant typing and value representations for resources are there, I was wondering what the remaining tasks to get resource support working are?

If it would be helpful, I would be more than happy to contribute to this!

wRPC is intended to be adopted as a hosted Bytecode Alliance project.
This is a tracking issue, which will be closed if/when bytecodealliance/governance#90 is approved

Currently there is some additional level of indirection added to trait parameter type signatures to work around latest Rust compiler reaching deadlock and/or recursion limit with recursive data structures. There should be a way to make this nicer post-MVP

Resources should be supported in wit-bindgen-wrpc. See #13 (comment) for some more context.

I think a simple first step of a prototype could look something like this:

• Each resource is assigned a ULID, which is used in place of the wrpc_transport instance
• All resources are stored indefinitely (until drop is called expliclitly) in a hashmap keyed by their ULIDs
• wit-bindgen-wrpc generates functionality to allocate a new resource and fully handles resource lifetime, implementations just need to provide handler implementations, just like in upstream wit-bindgen

cc @jacobvm04

We should explore testing the project with miri in CI

There should be a way to use Encode trait here - most likely we need to store a trait object in AsyncValue and change Encode receiver to take a (mutable?) ref.

floating point number NaNs have exactly one canonical representation in component-model specification, which we should match to be compliant.

Basically this is about adapting https://github.com/WebAssembly/component-model/blob/c3ef2a99f7c70b8189a889314569c0ce38c0433b/design/mvp/canonical-abi/definitions.py#L415-L441 in float encoding (although I do think we can be more lenient of decoding side and accept any NaN)

Refs WebAssembly/component-model#336 (comment)

We should run tests, rustfmt, clippy etc on each PR and require that for merge

Refs #4

Currently, resources can only be constructed using a constructor in Go bindgen. This effectively makes implementing resources in interfaces not using a constructor (like wasi:keyvalue https://github.com/WebAssembly/wasi-keyvalue/blob/219ea3612a53f1bf5b2d137551b22d0268fd3c58/wit/store.wit#L54) impossible, since the implementations should be able to "conjure a resource out of thin air" to support these kind of use cases.

It seems that the only way to handle this would be exposing the resource construction and method serving functionality in the generated bindings (or perhaps in wrpc module itself?) not tied to the constructor

go bindgen is very close to passing the whole wit-bindgen test suite, we should make sure that's complete and reenable it in the flake

Go bindgen should support renaming of generated types, since we went for "idiomaticity" over clash-resistence in the design

We now have functionality to walk the type in wrpc_introspect and compute the async values, we should do the same for wasmtime APIs directly. input-stream and such should be treated as async

wRPC values will always require a multiplexed connection and appropriate APIs for transmission and receival (due to values potentially containing nested async values, like streams or futures) - there may be use cases, however, where it may be desired to directly encode/decode wRPC values to/from single byte buffer - for example, for persistent storage. For those use cases, I propose to introduce pack/unpack functionality, which works the following way:

• All values can be packed - producing a single byte buffer with fully resolved/ready async values, if any
• packed values can always be unpacked
• Only fully resolved values can be packed (meaning that all incoming streams are fully received and finished and all futures are "ready" and their result is known). Packing operation may never complete if value being packed never resolves - therefore, packing operation MUST provide an API, which takes in a user-provided timeout.
• Just like in "core wRPC":
  • resolved futures future<T> are encoded as option::some variant of option<T>
  • resolved streams stream<T> are encoded as chunk_count:<core:uN> (chunk:<vec<T>>)^chunk_length with or without the "end" 0-length chunk. The special case of a "ready" empty stream is encoded as a stream containing a single, empty chunk
  • Encoding format is otherwise defined in WebAssembly/component-model#336 Binary.md

cc @protochron

Currently, we can only encode and decode flag types, which utilize at most 128 bits in Rust and 64 bits in Go, we should be able to handle 2^32 bits here

We should a wrpc-binary-nats binary, which takes a URL to a Wasm binary and runs it (for commands)/ serves it (for reactors) using NATS as the transport layer and Wasmtime as the runtime

Refs #4

Go signed LEB128 integers should be supported at least in the bindgen

Currently Index method is not implemented in wrpcnats.paramWriter, because as part of the root subject write it may lazily perform the handshake.
The implementation should be updated in such a way that the indexed parameter writers would not be able to write until the root writer performs the handshake. The transmission subject would then need to be communicated to the indexed writers.

Perhaps a possible way to handle this would be to use a RWMutex, which is locked on the root writer creation and unlocked once the handshake is complete. Indexed parameter writers Writes would then start with RLocking that shared mutex and block until the handshake is complete. We could also change init field to atomic.Bool here perhaps, which would let the indexed writers first check the atomic and only then attempt to RLock is they loaded false

https://github.com/wrpc/wrpc/blob/a75b04391524217058fb4c5284aee224ee8e4464/go/nats/client.go#L193

runtime-wasmtime should receive/send wasi:io streams as stream<u8>.
Most of this work is done, but we need to test it and ensure it actually works (and likely fix bugs).

Closing this issue requires a working example in examples

This project could benefit from fuzzing, we should investigate that an enable it in CI

We should add an IPC "transport", probably using Unix sockets on Unix and named pipes on Windows

Currently NATS transport uses "handshake" procedure to establish a two-way, point-to-point communication channel, it achieves this by setting up two NATS inboxes, one per peer. That is done, because there's no way to know if the peer is reachable by any other means than via the NATS broker. This works great for a single message exchange. However, in async scenarios or when payloads are large and do not fit in a single message, it would be great to have a way to negotiate a more efficient communication channel after the initial exchange. This basically means that we could conveniently do service discovery over NATS and then switch to a more efficient channel for actual data transfer.

Keeping the "0-rtt"-esque semantics of existing NATS transport, the way that a NATS -> QUIC upgrade could work is:

1. Client sends the (potentially truncated) parameter payload to $prefix.foo.bar. If the client is reachable on a particular UDP endpoint, it could send that endpoint as the "reply" header. (the "reply" header should probably be an ordered list containing the NATS inbox as the "fallback")
2. If the client's UDP endpoint is reachable by the server, it could reply directly on that endpoint. If not - it would just fall back to NATS. Similarly to the client, the server could now communicate the ordered list of endpoints that it would listen on.
3. Client continues data transfer over the more efficient transport, if the endpoint is reachable and otherwise falls back to NATS. In case of QUIC, it could also simply use the connection established by the server if the client communicated a UDP endpoint to the server

This way we could eliminate the middleman (NATS) allowing for efficient data transfer without sacrificing the ease of service discovery that NATS gives us.

This mechanism does not seem to be specific to NATS, but seems to be beneficial for any transport, which relies on some kind of broker service in the middle

Currently, async I/O future is generated for client bindings, when either parameter or result tuples contain at least one async type, we should do something similar for exports - probably generating impl Future<Output = anyhow::Result> as the last element in the tuple and failing the transmission if an error is returned (instead of a clean byte stream shutdown)

wrpc-runtime-wasmtime should support static and dynamic resources. Now that Wasmtime 20 is released, this should be possible to implement using stable APIs

Refs #13

The transport abstraction has been reworked in #81, we should:

• migrate wit-bindgen-wrpc to the new transport API
• replace wrpc-transport by wrpc-transport-next (the end result is that wrpc-transport-next is renamed to wrpc-transport)
• deprecate wrpc-types crate

Currently, invoke returns an io.Writer, and it is assumed that in case parameters are empty, the user must write an empty buffer (e.g. nil) to trigger the exchange. Instead of this hacky procedure, the invoke method should take in a []byte, which will be flushed fully before any of the bytes written on the returned io.Writer will be transported.
invoke then can eagerly send the payload before it returns

Refs #93 #82

After giving it some thought, trying different things and gathering feedback, I think I finally figured out a reasonable resource design for wRPC.
First, a few key points:

• It is generally expected that wRPC transports are namespaced (and possibly multi-tenant, where relationship of tenants to namespaces is 1:N)
• Resources cannot escape the namespace and can only be used within the namespace they originated from.
• Resource handles uniquely identify the origin of the resource and the resource itself in that origin, both of these are application-specific (and may include in itself e.g. the transport namespace)

With this, I think we can untangle the complicated OOP-centric resource design and accept that methods are really just functions, which take borrowed resource handles as first parameters, and they are handled exactly the same as all other functions. (except, perhaps, that for each exported resource, a wRPC peer must eagerly serve drop function, which is not explicitly defined in WIT)

In distributed, multi-namespace use cases, the application should be able to derive the namespace that resource originated from using the resource handle. Defining exactly how this would work is out-of-scope for wRPC, however wRPC may provide utility libraries for building these features e.g. distributed resource tables.

I think that "resources" on the protocol level should just be opaque byte blobs, list<u8>, which are entirely application specific

For example, let's consider Wasmtime binary using wRPC for providing host plugins.
Whenever a polyfilled (how about substituted?) resource is received or sent on the wire, it could be encoded as a following WIT record:

record handle {
   pid: u32,
   id: u32
}

• pid uniquely identifies the Wasmtime process
• id uniquely identifies the resource in the WASI context table, i.e. it's just the u32 index, since a single Wasmtime process can only run a single Wasm component

In scenarios where there may be multiple Wasmtime processes simultaneously exporting a particular resource, the pid could be used to figure out which exact Wasmtime process keeps the resource in memory and using some out-of-band, Wasmtime-specific mechanism acquire the resource state.

To enable this, in Rust, wrpc_transport crate would define a Resource struct roughly as:

struct Resource<T> { data: Vec<u8>, _ty: PhantomData<T> }
impl<T> AsRef<[u8]> for Resource<T> { .. }
impl<T> From<Vec<u8>> for Resource<T> { .. }
impl<T> From<Resource<T>> for Vec<u8> { .. }
impl<T> Resource<T> { pub fn new(data: Vec<u8>) -> Self { .. } }

I'm not sure what's best to do here about the drops, probably for now implementers will just have to manually call drop on owned handles, especially since it's potentially a fallible operation. We may want to opt for Borrow<T> and Own<T> records instead of a singular Resource<T>, similar to what's already done for Go https://github.com/wrpc/wrpc/blob/01a536b18c8522469a33cb72a2d5f702585a27ee/go/wrpc.go#L18-L43

For example, for https://github.com/WebAssembly/wasi-keyvalue/ generated Ruststore.open function signature could look like:

async fn(identifier: &str) -> Result<wrpc_transport::Own<store::Bucket>, store::Error>

@jacobvm04 what do you think?

wrpc-transport crate is a bit of a mess with leaky abstractions - it served well to reach an MVP with NATS transport, but it's time to rework it to better suit this projects needs.
Largely this should be based on wrpc Go package design
The biggest requirements here are:

• handshake and accept logic should be moved into the individual transport implementations, wrpc-transport should just operate on plain AsyncRead and AsyncWrite handles with indexing
• AsyncValue and AsyncTransmission should be removed (#1)
• #2

Since we believe wRPC will be a foundational mutli-stakeholder project, there's a good chance it may be moved to another organization. We can keep from modifying our code if a transition occurs by providing a vanity url.

Create a vanity URL with github pages to go.wrpc.io.

The go work is currently in a subdir at github.com/wrpc/wrpc/go. If we use github pages, we need to test if we can host an index.html using modgen so that go.wrpc.io -> wrpc.github.io/wrpc/go