-
Notifications
You must be signed in to change notification settings - Fork 24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
examples/rust: add echo-stream-nats-{client,server} #217
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice, thanks!
33e6b29
to
1de2418
Compare
rebased and fixed-up a small merge conflict in |
indeed, that's because wRPC does not handle chunking and it's expected that implementations would handle that instead, I believe https://docs.rs/futures/latest/futures/stream/trait.StreamExt.html#method.ready_chunks should be able to be used out-of-the-box here on sender side
The intention here is to be able to poll both the stream and the I/O future concurrently for most use cases providing for clean separation of data and I/O error handling. I think we need to have both separate for lower-level use cases, however I certainly agree that providing a wrapper, which could take these two and return a single future/stream would be ideal.
That's a bit tricky, async support in component model is currently WIP (latest draft at https://github.com/WebAssembly/component-model/blob/main/design/mvp/Async.md, refs WebAssembly/component-model#363). I believe there is a set of patches for Wasmtime, which would allow using async in components, but I have not explored that myself yet. I also don't think we should depend on an unreleased version of Wasmtime in wRPC (we could, however, add an additional runtime using one) Other than that, I'm thinking to work on a wRPC Would you perhaps be interested in working on (beginnings of) a reflection API? Basically define all WIT kinds in WIT and perhaps have some way to "construct" a |
Small follow-up, I suggest to take a look at the slightly reworked stream usage at wrpc/examples/rust/streams-nats-client/src/main.rs Lines 53 to 95 in 6ea5b37
|
Ah, yes, this certainly makes sense, thanks!
Thanks! I'm new to the WIT ecosystem, and while I'm not entirely sure where to get started on such a reflect API, I'd be interested in working on that given a bit more context. Is the idea to provide non-blocking/blocking APIs within a sync component for working with a And would it be possible currently to use |
This is essentially a copy of the
hello-nats-{client,server}
example, but with a bi-directional stream (server echos the client) that came out of me wanting to know if this functionality works.There are a few things I'd like to note:
stream<u64>
but the bindings are forVec<u64>
.echo
on the client is a tuple with a stream and a future, where the future has to be polled before the stream will work. This feels clunky; could the future be implemented as part of the stream?wit_bindgen::generate!
doesn't implementstream
(orfuture
) yet, so I'm not sure if implementing this as a component example is feasible?I'd like to get this working with a component example, so I'd be happy to help out with any of the above.