Skip to content
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.

Sign up for GitHub

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

Jump to bottom

feat(*): Updates messaging to support request-reply #21

Closed
wants to merge 1 commit into from
Closed

feat(*): Updates messaging to support request-reply #21

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -45,7 +45,7 @@ Overall, the messaging interfaces aim to make it easier to build complex and sca
### Non-goals

- The messaging service interfaces do not aim to provide advanced features of message brokers, such as broker clustering, message persistence, or guaranteed message delivery. These are implementation-specific details that are not addressed by the interfaces.
- The messaging service interfaces do not aim to provide support for every possible messaging pattern or use case. Instead, they focus on the common use cases of pub-sub and push-based message delivery. Other messaging patterns, such as request-reply or publish-confirm-subscribe, are outside the scope of the interfaces.
- The messaging service interfaces do not aim to provide support for every possible messaging pattern or use case. Instead, they focus on the common use cases of pub-sub, push-based message delivery, and request-reply. Other messaging patterns, such as publish-confirm-subscribe, are outside the scope of the interfaces.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Adding support for request-reply was rejected during our stakeholder review - here's a relevant comment explaining why: #8 (comment)

Copy link
Collaborator Author

@thomastaylor312 thomastaylor312 Mar 4, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So I missed that when I was digging around. However, I think I need to do some more thinking on the reasoning there. I understand the motivation as described there for not adding it, but based on everything I've seen in real usage of the wasmcloud messaging interface and in my review of most of the common messaging systems, request/reply showed up everywhere. Let me do some more reading and come back to this, because, like you mentioned, this should reflect real world usage

- The messaging service interfaces do not aim to provide a specific implementation of a message broker. Instead, they provide a standard way to interact with any message broker that supports the interfaces.

### API walk-through
Expand Down
2 changes: 2 additions & 0 deletions wit/producer.wit
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,5 +1,7 @@
interface producer {
use messaging-types.{client, channel, message, error};

/// Sends a message to the given channel/topic. This topic can be overridden if a message has a
/// non-empty topic field
send: func(c: client, ch: channel, m: list<message>) -> result<_, error>;
}
21 changes: 7 additions & 14 deletions wit/types.wit
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -23,22 +23,15 @@ interface messaging-types {
extensions: option<list<tuple<string, string>>>
}

/// Format specification for messages
/// - more info: https://github.com/clemensv/spec/blob/registry-extensions/registry/spec.md#message-formats
/// - message metadata can further decorate w/ things like format version, and so on.
enum format-spec {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

format-spec wasn't part of the original interface, but was added during our stakeholder review. Here's some relevant comments you may want to take a look at:
(1) #9 (comment)
(2) #9 (comment)

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmmm...I think agree with that second comment that this should be a either a bare string or at least called content-type as the link in the comment was about registry stuff and nothing to do with content-type. The thread in (2) suggests this but I didn't seem to understand the argument that format-spec should be the thing we use

cloudevents,
http,
amqp,
mqtt,
kafka,
raw
}

/// A message with a binary payload, a format specification, and decorative metadata.
/// A message with a binary payload and additional information
record message {
/// The topic or subject this message was received or should be sent on
topic: string,
/// An optional topic for use in request/response scenarios
reply-to: option<string>,
/// An opaque blob of data
data: list<u8>,
format: format-spec,
/// Optional metadata (also called headers or attributes in some systems) attached to the message
metadata: option<list<tuple<string, string>>>
}
}
Loading