Simplifies wasi-messaging interface with feedback #24
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This makes several updates to the messaging interface. Initially the README said that this wasn't going to support request/reply, but based on my reading of the Kafka, NATS, MQTT, and SQS APIs, this is a fairly common pattern. Another piece of evidence here is what I've seen as a wasmCloud maintainer from our users. Request/reply is one of the more common things we see with a messaging service. Please note that this doesn't _require_ the use of a reply-to topic, just exposes it for use. I also did a few other changes here. First is that I added the topic to the message. This was common across all systems and is often used by code to select the appropriate logic to perform. I also removed the format field as this didn't seem to be a common parameter across various services. We could definitely add a content-type member to this record in the future if needed, but I think much of that can be passed via the metadata field. There are other things I might suggest some changes to, but I want to think on them some more and open some issues to discuss them first Signed-off-by: Taylor Thomas <[email protected]>
This PR integrates various changes from talking to current users of messaging in the community as well as conversations among the champions Signed-off-by: Taylor Thomas <[email protected]>
I also deleted the examples.md for now until we settle on the interface. It will be easier to add back in once we have some real world examples to point at Signed-off-by: Taylor Thomas <[email protected]>
Also removes extensions as a guest configuration option (for now) Signed-off-by: Taylor Thomas <[email protected]>
In many of the interfaces out there right now, we've moved more towards just calling these things config Signed-off-by: Taylor Thomas <[email protected]>
Also removes the channel parameter I forgot to remove in a previous commit Signed-off-by: Taylor Thomas <[email protected]>
…ions One of the uses of request-multi is to support a scatter/gather operation. In these cases, you might not know how many requests you are going to receive, so you can't set expected replies. Generally these wait until timeout and then return the results. This commit adds the ability to support all the different use cases for request-multi Signed-off-by: Taylor Thomas <[email protected]>
After a whole bunch of feedback from the community, I realized we were still trying to make this interface too much. So I dramatically paired back the interface to be purely focused on message passing. Further features like ack/nack, guaranteed delivery, and so on are now out of scope (see the README for full details). This was partly inspired by a discussion in the CNCF Wasm WG around this interface. To be perfectly frank, the level I paired this down to is essentially the same level of guarantees offered by the wasmCloud [messaging interface](https://github.com/wasmCloud/messaging). The main reason being is that there are people actually using that interface for real applications (with real host implementations). If we can come to agreement on a simpler interface, it will be easier to add in functionality such as the things I stripped out in this commit. Please let me know any feedback you have around this, focusing on whether or not this covers at least the most basic scenarios Signed-off-by: Taylor Thomas <[email protected]>
…d nits Signed-off-by: danbugs <[email protected]>
Signed-off-by: danbugs <[email protected]>
yordis
reviewed
Oct 4, 2024
Signed-off-by: danbugs <[email protected]>
yordis
reviewed
Oct 4, 2024
yordis
reviewed
Oct 4, 2024
yordis
reviewed
Oct 4, 2024
yordis
reviewed
Oct 4, 2024
Signed-off-by: danbugs <[email protected]>
Mossaka
reviewed
Oct 4, 2024
jocrau
reviewed
Oct 4, 2024
jocrau
reviewed
Oct 4, 2024
yordis
reviewed
Oct 4, 2024
…metadata method, added new-line at the end of files, improved argument names, removed .gitignore, improved documentation, changed get-subscriptions function name Signed-off-by: danbugs <[email protected]>
yordis
reviewed
Oct 4, 2024
danbugs
force-pushed
the
danbugs/simplified-interface
branch
from
7b8f834 to
d2aeb72
Compare
Signed-off-by: danbugs <[email protected]>
danbugs
force-pushed
the
danbugs/simplified-interface
branch
from
d2aeb72 to
c811951
Compare
|
This PR has been marinating for a while. So, if there's no additional feedback, I am hoping to merge this by Wednesday to maybe discuss moving the interface to Phase 2 on Thursday's WASI Subgroup video meeting. |
yordis
reviewed
Oct 29, 2024
Signed-off-by: danbugs <[email protected]>
yordis
approved these changes
Oct 30, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR is a follow-up to #23 . Like it, this also incorporates various points of feedback from interface champions, users, and working group discussions. In addition, it also simplifies the wasi-messaging interface as per feedback in the prior PR.
The main changes to review are:
README.consumer.wit.messaging-guestasincoming-handler.request-reply.wit.types.witincluding creating concrete error types, and adding a message resource.