diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml index 45c37c2..7669187 100644 --- a/.github/workflows/main.yml +++ b/.github/workflows/main.yml @@ -13,5 +13,5 @@ jobs: - uses: actions/checkout@v2 - uses: WebAssembly/wit-abi-up-to-date@v17 with: - wit-bindgen: '0.30.0' + wit-bindgen: '0.34.0' worlds: 'imports imports-request-reply messaging-core messaging-request-reply' diff --git a/README.md b/README.md index 01f7bbe..1d303b8 100644 --- a/README.md +++ b/README.md @@ -101,4 +101,4 @@ It would make sense for a lot of these functions to be asynchronous, but that is the component model. Asynchronous support will be added as part of WASI Preview 3. When async support becomes available, we plan to update the wasi-messaging interface to incorporate asynchronous patterns. -> **Note**: Ensure you have version 0.30.0 of `wit-bindgen` installed to avoid compatibility issues. +> **Note**: Ensure you have version 0.34.0 of `wit-bindgen` installed to avoid compatibility issues. diff --git a/imports-request-reply.md b/imports-request-reply.md index bdfa2d6..949b348 100644 --- a/imports-request-reply.md +++ b/imports-request-reply.md @@ -66,7 +66,6 @@ This allows the component to perform request/reply messaging patterns.
[constructor]message: func
topic
: string
data
: list<u8
>[method]message.set-topic: func
Set the topic/subject/channel this message should be sent on
-[method]message.content-type: func
An optional content-type describing the format of the data in the message. This is sometimes described as the "format" type
@@ -145,6 +137,13 @@ messagekey
: string
value
: string
[method]message.set-metadata: func
Set the metadata
+[method]message.remove-metadata: func
Remove a key-value pair from the metadata
message
>>, error
>reply: func
Replies to the given message with the given response message. The details of which channel +
Replies to the given message with the given response message. The details of which topic the message is sent to is up to the implementation. This allows for reply-to details to be handled in the best way possible for the underlying messaging system.
Please note that this reply functionality is different than something like HTTP because there @@ -247,6 +246,9 @@ where the reply is sent and the connection is closed.
#### `type error` [`error`](#error)+#### `type topic` +[`topic`](#topic) +
----
send: func
producer
interface for sending messages.
[constructor]message: func
topic
: string
data
: list<u8
>producer
interface for sending messages.
-[method]message.set-topic: func
Set the topic/subject/channel this message should be sent on
-[method]message.content-type: func
An optional content-type describing the format of the data in the message. This is sometimes described as the "format" type
@@ -144,6 +136,13 @@ messagekey
: string
value
: string
[method]message.set-metadata: func
Set the metadata
+[method]message.remove-metadata: func
Remove a key-value pair from the metadata
+#### `type topic` +[`topic`](#topic) +
----
send: func
[constructor]message: func
topic
: string
data
: list<u8
>[method]message.set-topic: func
Set the topic/subject/channel this message should be sent on
-[method]message.content-type: func
An optional content-type describing the format of the data in the message. This is sometimes described as the "format" type
@@ -149,6 +141,13 @@ messagekey
: string
value
: string
[method]message.set-metadata: func
Set the metadata
+[method]message.remove-metadata: func
Remove a key-value pair from the metadata
+#### `type topic` +[`topic`](#topic) +
----
send: func
handle: func
Whenever this guest receives a message in one of the subscribed topics, the message is -sent to this handler. The guest is responsible for matching on the channel and handling the +sent to this handler. The guest is responsible for matching on the topic and handling the message accordingly. Implementors (such as hosts) calling this interface should make their own decisions on how to handle errors returned from this function.
get-topics: func
Returns a list of topics (represented as string
s) at runtime the guest should be subscribed
-to at runtime. Implementors should consider also allowing subscriptions to be made at compile time
+Implementors should consider also allowing subscriptions to be made at compile time
via some sort of configuration file. This function is intended to be called at the start of the
guest's lifecycle before any messages are sent.
[constructor]message: func
topic
: string
data
: list<u8
>[method]message.set-topic: func
Set the topic/subject/channel this message should be sent on
-[method]message.content-type: func
An optional content-type describing the format of the data in the message. This is sometimes described as the "format" type
@@ -151,6 +143,13 @@ messagekey
: string
value
: string
[method]message.set-metadata: func
Set the metadata
+[method]message.remove-metadata: func
Remove a key-value pair from the metadata
message
>>, error
>reply: func
Replies to the given message with the given response message. The details of which channel +
Replies to the given message with the given response message. The details of which topic the message is sent to is up to the implementation. This allows for reply-to details to be handled in the best way possible for the underlying messaging system.
Please note that this reply functionality is different than something like HTTP because there @@ -253,6 +252,9 @@ where the reply is sent and the connection is closed.
#### `type error` [`error`](#error)+#### `type topic` +[`topic`](#topic) +
----
send: func
handle: func
Whenever this guest receives a message in one of the subscribed topics, the message is -sent to this handler. The guest is responsible for matching on the channel and handling the +sent to this handler. The guest is responsible for matching on the topic and handling the message accordingly. Implementors (such as hosts) calling this interface should make their own decisions on how to handle errors returned from this function.
get-topics: func
Returns a list of topics (represented as string
s) at runtime the guest should be subscribed
-to at runtime. Implementors should consider also allowing subscriptions to be made at compile time
+Implementors should consider also allowing subscriptions to be made at compile time
via some sort of configuration file. This function is intended to be called at the start of the
guest's lifecycle before any messages are sent.