diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml index 9ba6465..a084cc6 100644 --- a/.github/workflows/main.yml +++ b/.github/workflows/main.yml @@ -13,4 +13,5 @@ jobs: - uses: actions/checkout@v2 - uses: WebAssembly/wit-abi-up-to-date@v17 with: - wit-bindgen: '0.16.0' + wit-bindgen: '0.18.0' + worlds: 'imports messaging' diff --git a/imports.md b/imports.md new file mode 100644 index 0000000..cc4b825 --- /dev/null +++ b/imports.md @@ -0,0 +1,184 @@ +
wasi:messaging/messaging-types@0.2.0-draftwasi:messaging/producer@0.2.0-draftwasi:messaging/consumer@0.2.0-draftresource clientA connection to a message-exchange service (e.g., buffer, broker, etc.).
+resource errorTODO(danbugs): This should be eventually extracted as an underlying type for other wasi-cloud-core interfaces.
+type channelstring
There are two types of channels: +- publish-subscribe channel, which is a broadcast channel, and +- point-to-point channel, which is a unicast channel. +
The interface doesn't highlight this difference in the type itself as that's uniquely a consumer issue.
+record guest-configurationConfiguration includes a required list of channels the guest is subscribing to, and an optional list of extensions key-value pairs +(e.g., partitions/offsets to read from in Kafka/EventHubs, QoS etc.).
+channels: list<channel>extensions: option<list<(string, string)>>enum format-specFormat specification for messages
+record messageA message with a binary payload, a format specification, and decorative metadata.
+data: list<u8>format: format-specmetadata: option<list<(string, string)>>[static]client.connect: func[static]error.trace: functype client+#### `type channel` +[`channel`](#channel) +
+#### `type message` +[`message`](#message) +
+#### `type error` +[`error`](#error) +
+---- +
send: funcerror>>type client+#### `type message` +[`message`](#message) +
+#### `type channel` +[`channel`](#channel) +
+#### `type error` +[`error`](#error) +
+#### `type guest-configuration` +[`guest-configuration`](#guest_configuration) +
+---- +
subscribe-try-receive: funcBlocking receive for t-milliseconds with ephemeral subscription – if no message is received, returns None
+subscribe-receive: funcBlocking receive until message with ephemeral subscription
+update-guest-configuration: func'Fit-all' type function for updating a guest's configuration – this could be useful for:
+gc: guest-configurationerror>>complete-message: funcA message can exist under several statuses: +(1) available: the message is ready to be read, +(2) acquired: the message has been sent to a consumer (but still exists in the queue), +(3) accepted (result of complete-message): the message has been received and ACK-ed by a consumer and can be safely removed from the queue, +(4) rejected (result of abandon-message): the message has been received and NACK-ed by a consumer, at which point it can be:
+m: messageerror>>abandon-message: funcm: messageerror>>wasi:messaging/messaging-types@0.1.0wasi:messaging/producer@0.1.0wasi:messaging/consumer@0.1.0wasi:messaging/messaging-types@0.2.0-draftwasi:messaging/producer@0.2.0-draftwasi:messaging/consumer@0.2.0-draftwasi:messaging/messaging-guest@0.1.0wasi:messaging/messaging-guest@0.2.0-draftresource clientresource clientA connection to a message-exchange service (e.g., buffer, broker, etc.).
-resource errorresource errorTODO(danbugs): This should be eventually extracted as an underlying type for other wasi-cloud-core interfaces.
-type channeltype channelstring
There are two types of channels: - publish-subscribe channel, which is a broadcast channel, and - point-to-point channel, which is a unicast channel.
The interface doesn't highlight this difference in the type itself as that's uniquely a consumer issue.
-record guest-configurationrecord guest-configurationConfiguration includes a required list of channels the guest is subscribing to, and an optional list of extensions key-value pairs (e.g., partitions/offsets to read from in Kafka/EventHubs, QoS etc.).
channels: list<channel>extensions: option<list<(string, string)>>channels: list<channel>extensions: option<list<(string, string)>>enum format-specenum format-specFormat specification for messages
record messagerecord messageA message with a binary payload, a format specification, and decorative metadata.
data: list<u8>format: format-specmetadata: option<list<(string, string)>>data: list<u8>format: format-specmetadata: option<list<(string, string)>>[static]client.connect: func[static]client.connect: funcname: stringname: string[static]error.trace: func[static]error.trace: functype clienttype client-#### `type channel` +#### `type channel` [`channel`](#channel)
-#### `type message` +#### `type message` [`message`](#message)
-#### `type error` +#### `type error` [`error`](#error)
----
send: funcsend: funcerror>>type clienttype client-#### `type message` +#### `type message` [`message`](#message)
-#### `type channel` +#### `type channel` [`channel`](#channel)
-#### `type error` +#### `type error` [`error`](#error)
-#### `type guest-configuration` +#### `type guest-configuration` [`guest-configuration`](#guest_configuration)
----
subscribe-try-receive: funcsubscribe-try-receive: funcBlocking receive for t-milliseconds with ephemeral subscription – if no message is received, returns None
subscribe-receive: funcsubscribe-receive: funcBlocking receive until message with ephemeral subscription
update-guest-configuration: funcupdate-guest-configuration: func'Fit-all' type function for updating a guest's configuration – this could be useful for:
error>>complete-message: funccomplete-message: funcA message can exist under several statuses: (1) available: the message is ready to be read, (2) acquired: the message has been sent to a consumer (but still exists in the queue), @@ -172,47 +172,47 @@
error>>abandon-message: funcabandon-message: funcerror>>type messagetype message-#### `type guest-configuration` +#### `type guest-configuration` [`guest-configuration`](#guest_configuration)
-#### `type error` +#### `type error` [`error`](#error)
----
configure: funcconfigure: funcReturns the list of channels (and extension metadata within guest-configuration) that this component should subscribe to and be handled by the subsequent handler within guest-configuration
guest-configuration, own<error>>handler: funchandler: funcWhenever this guest receives a message in one of the subscribed channels, the message is sent to this handler