Open dicej opened 1 year ago
I'm also wondering if it should take a client
parameter, in case the guest wants to use it e.g. to publish new messages to the same client it received the message from. That would save the trouble of opening a second handle.
I'm also wondering if it should take a client parameter, in case the guest wants to use it e.g. to publish new messages to the same client it received the message from. That would save the trouble of opening a second handle.
that would be nice for RPC-y pub-sub.
So for the channel part of this, that is part of the message itself and I think that is a fairly easy thing to consume. The passing a client
parameter is interesting as it allows the caller to specify which client should be used to respond to something. I do find it a little awkward though for the use cases that don't need a client. I don't think constructing a client would be too much overhead as I figure most hosts would probably cache it, correct? So the first time might be a tiny bit of overhead depending on the underlying implementation, but after that it should be pretty quick
So for the channel part of this, that is part of the message itself and I think that is a fairly easy thing to consume.
Sorry, I'm not quite following this. Do you mean to say the channel should be part of the message
type? E.g. a field to be added here?
Whoops sorry @dicej, I did do it in my open PR (which I am still doing some digging on around request/reply support): https://github.com/WebAssembly/wasi-messaging/pull/21/files#diff-a8f42ac7cc164b46639a30d22f97ca796bd47991da55edc0022578930424be06R29.
But it isn't on main yet
So in other words, I think it should be part of the message
Thanks for clarifying -- that works for me.
This would tell the guest which channel the message was received from and make it a more symmetric with
wasi:messaging/producer/send
, which takes achannel
.