Closed gustav-b closed 8 years ago
@gustav-b indeed you're correct. Cony is kind of static about AMQP topology and was designed to avoid burden of running AMQP setup procedures on reconnect event.
Thanks @kron4eg,
My point was that the exchange name and routing key of a message isn't really part of the topology (just like the message headers and payload aren't a part of the topology). Therefor I found it a confusing that they were passed when creating a Publisher. I see the convenience of not having to pass the two strings on each publish, but it makes the library less flexible. I'll close this unless there is intention to change the design.
@gustav-b the library grown out of our internal needs. I was tired of writing stupid setup procedures every time from scratch. So it's just fit for Assembla's usecase. But if you could manage to introduce desired dynamism without breaking API, we'd happily accept your PR :)
If I understand the design of cony correctly, the Publishers of a Client must be declared (complete with exchange and routing key) upfront, before the Client's loop is started? That is, there is no way to change the exchange or routing key of a Publisher, or to add Publishers after the client has been started?
If so, I see some inflexibility with this design. It prevents message routing keys and exchange to be generated at runtime, while the rest of the message can be dynamic. One could work around it by creating a new Client+Publisher per publishing, but it is costly to create a new connection on each publish.