rvolosatovs
commented
6 months ago 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_transportlevel 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 in
wrpc_transport::Clientmethodinstancefield (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
- Current thinking is that a unique resource identifier will be used in
wrpc-runtime-wasmtimein 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 https://github.com/wrpc/wrpc/pull/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
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!