In my example I think of a message broker communicating in AMQP 1.0, but I think the question also applies to #451.
I would like to use a topic on a message broker as source. If I understand the current state of discussion correctly, that would mean an according source Provisioner would configure some receive adapter that would basically act as AMQP client and push the events into a channel. As you usually do not subscribe directly to a topic, there would also be a queue on the broker, and the client would subscribe to that. On knative side the channel would most likely again use a broker and persist the event, yet again.
I'm wondering, if instead of this approach there could be AMQP channels that could be used by all sources supporting AMQP. This way, a source could just be the topic, and a channel could handle the queue for subscribers. Finally, it would now be the channel (or the subscription) using a receive adapter to push events into services.
I suppose both approaches have pros and cons. The first approach takes the burden of fan-out from the upstream broker, while the second approach has one persistence step less.
In my example I think of a message broker communicating in AMQP 1.0, but I think the question also applies to #451.
I would like to use a topic on a message broker as source. If I understand the current state of discussion correctly, that would mean an according source Provisioner would configure some receive adapter that would basically act as AMQP client and push the events into a channel. As you usually do not subscribe directly to a topic, there would also be a queue on the broker, and the client would subscribe to that. On knative side the channel would most likely again use a broker and persist the event, yet again.
I'm wondering, if instead of this approach there could be AMQP channels that could be used by all sources supporting AMQP. This way, a source could just be the topic, and a channel could handle the queue for subscribers. Finally, it would now be the channel (or the subscription) using a receive adapter to push events into services.
I suppose both approaches have pros and cons. The first approach takes the burden of fan-out from the upstream broker, while the second approach has one persistence step less.