Producer does not need to specify what type of a channel to send message to

[Mossaka]

The current way of how a channel type is defined is

variant channel {
    queue(string),
    topic(string)
}

This explictly requires the user to determine whether to use a queue or a topic.

This is intended for a consumer to choose between a competing queue or a shared topic, but it does not make sense for a publisher to know whether its sending a message to a queue or a topic.

Thus I propose we change the signature of publish function from

publish: func(b: broker, c: channel, e: event) -> result<_, error>

to

publish: func(b: broker, c: string, e: event) -> result<_, error>

wdyt? @danbugs

[danbugs]

As is, we currently allow a producer to target two channels w/ same name but different behaviours (i.e., competitively or not), and, if we make that proposed change, that would no longer be the case. That said, allowing duplicate names prob. isn't that big of a requirement, so I'd be okay w/ making this modification.

I remember some folks upstream were apprehensive of having identification w/ dynamic types like strings, but I guess channel always was just an indirection.

[Mossaka]

Yeah agreed that string might not be the final type for representing "where the message should go" for publishers, but my main point is that the difference between "competing queues" vs. "cooperative topics" should be transparent to the POV of publishers as they are concepts purely exist in the consumer side.

[danbugs]

There's a significant re-write of this interface currently brewing that will, hopefully, address your concerns too.