SPodjasek
commented
7 years ago I'll opt for following signature:
publish($body!, \%headers?, *@params)which will allow to call it like this:
->publish($body, { header => 'value' }, routing_key => 'something',
mandatory => 1, immediate => 0);
->publish($body, routing_key => 'something');
->publish($body, { header => 'value' });
->publish($body);With following rules:
- if $body is hashref default content_type is set to application/json and $body is encoded to JSON string, otherwise it will be passed as-is,
- if second argument is hashref it will be merged with default headers, replacing any pre-existing values, if it's defined but not a hashref it will be treated as below,
- any other (slurpy) arguments will be treated as key/value pairs and merged with AMQP publish method default parameters
What do you think?
tyldum
kraih
AFAICS, the routing key is derived from the ?queue query-param. This means you need one publisher per routing key, while my design has a very dynamic routing key that is unlikely to repeat more than a few times per week.
I would like to introduce the routing key to publish(). I can create a PR, but I was debating with myself over semantics:
->publish('body',\%headers,'routing_key') vs ->publish('body', { headers => \%headers, routing_key => 'some.routing.key' }) The second one opens up for more flexibility for other options needed.