Expected host behavior when message properties are not supported for implementation

[rvolosatovs]

Support for content-type and metadata/headers across different message queues and services is not uniform. For example, RabbitMQ has built-in support for content-type, but NATS.io does not.

What's the correct behavior on the host's part when content-type and/or metadata is set in the guest message, but not supported by the underlying implementation?

In scenario where a message is received by the guest via incoming-handler#handle, the resource is associated with the concrete implementation of a message queue it originated from, therefore we can make assumptions on which properties are supported and which are not (like is done in #29)

In cases, where the guest constructs a message, it will only be associated with a concrete message queue once it's passed as a parameter to e.g. producer#send. What is the expected behavior for the host in case e.g. a guest message with content-type set is passed to a types.client, which is associated with NATS.io, which does not support content-type?

One potential solution I see here is:

• Exposing supports-metadata: func() -> bool and supports-content-type: func() -> bool on types.client
• Removing

  wasi-messaging/wit/request-reply.wit

  Line 46 in 4ee59bb

  reply: func(reply-to: borrow<message>, message: message) -> result<_, error>;

• Exposing reply as a getter on the message, therefore enforcing that replies are sent using a specific types.client via producer#send
• Adding remove-content-type to message

With this functionality, I think we can enforce that, e.g. passing a message carrying content-type to producer#send using a client, which does not support it, results in a hard error.

Another potential improvement here is removing the message constructor altogether and instead, exposing a new_message method on the client.

It looks like there also should be some way to derive a client from an incoming message

[danbugs]

What's the correct behavior on the host's part when content-type and/or metadata is set in the guest message, but not supported by the underlying implementation?

I'm a bit unclear on why a host should provide any support content-type or metadata. Both these fields are optional and should only be decorative. That is, they should not be interpreted by a host:

wasi-messaging/wit/types.wit

Lines 41 to 43 in 4ee59bb

	/// Optional metadata (also called headers or attributes in some systems) attached to the
	/// message. This metadata is simply decoration and should not be interpreted by a host
	/// to ensure portability across different implementors (e.g., Kafka -> NATS, etc.).

This is done on purporse to not hurt the portability of the interface.

With your proposed changes, would I still be able to grab a component that uses wasi:messaging and swap its backend (say, from NATS to RabbitMQ) w/ only config changes?