Dynamic Resource Support

[jacobvm04]

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!

[rvolosatovs]

Thanks for opening an issue about this!

Work is currently underway to support resources in wrpc-runtime-wasmtime, but it was paused for a few weeks at this point - I am planning to get back to it later this week and hopefully have this piece working by next week.
Note also, that in PoC there already was resource support https://github.com/wrpc/wrpc/tree/poc, but it depended on a wasmtime fork, which would not be necessary anymore since wasmtime 20 was released yesterday (https://github.com/bytecodealliance/wasmtime/releases/tag/v20.0.0) and I believe it includes all the necessary bits to actually be able to construct resources in polyfills.

In terms of work still to be done:

• On the protocol and wrpc_transport level I don't think any/many changes are necessary, but there's still a little bit of design work to do regarding the method invocation scheme:
  • Current thinking is that a unique resource identifier will be used inwrpc_transport::Client method instance field (which could be e.g. a NATS subject uniquely identifying a resource or e.g. a URL in a future). I had made a small change locally to change the instance argument from a string to an enum allowing for a transport-specific identifier to be used here, but I'm still on the fence about this change - maybe just strings are fine for MVP and simplicity
  • Wasmtime prefixes method names with e.g. [method], but I don't think we need that give the above
  • There probably should be some special treatment for drop (and maybe something else) if it's not a reserved method name, I'd need to double-check that
• wrpc-runtime-wasmtime in in-progress and really was blocked on wasmtime 20 release (I've been using a git pin locally for dev), now that's done it should be quite fast to figure that out

So the pieces above are what is in-flight, mostly it's wrpc-runtime-wasmtime work.
I've started this before I've integrated the wit-bindgen-wrpc in #11 - I did have to address some things related to resources as part of it, but not much.

I guess the trickiest part there would be the resource lifetime management - i.e. knowing when would be the right time to drop a resource and how that relates to resource ownership. Actually I had a short discussion with @lukewagner around this topic and he gave me a great idea here being that each party receiving a resource could notify the resource owner - this would let the resources track the current owner/borrower of each resource and either "ask" them if the resource is still in use (or simply if the peer is still "up") or treat this as a "heartbeat" of sorts - or maybe both.

I'm also still not sure if resource handling would be something that belongs in wrpc_transport, I feel like it sits at a higher level of abstraction and it would be difficult to come up with a reasonable abstraction here, which would work for both a native "plugin" use case (wit-bindgen-wrpc) and runtime embedding (wrpc-runtime-wasmtime) use case - maybe I'm wrong, but at least with Wasmtime I think all resources would be able to be stored in Wasmtime table, which is not the case with wit-bindgen-wrpc.

Anyway, if you would be interested, adding self-contained resource support to wit-bindgen-wrpc would be very appreciated and I'm happy to e.g. jump on a call to discuss the possible approaches there.

I'll file some issues

[rvolosatovs]

Refs #101