[rabbitmq-discuss] RabbitMQ 2.6.0 is released

[Michael Bridgen]

On 09/01/2011 09:06 AM, Matthew Sackman wrote:
> On Thu, Sep 01, 2011 at 12:52:18AM +0100, Michael Bridgen wrote:
>> Surely the point is that RabbitMQ must be told about the appropriate
>> mirroring, yet it's very unlikely to be the person writing an
>> application that knows it (and especially not in terms of the Erlang
>> node names!), so putting it in the queue.declare method is rather
>> erm, hopeful. It really should be part of the operational interface,
>> not the application interface.
>
> Indeed. Personally, I'd be keen to extend AMQP with additional methods
> that allow such things to be manipulated, thus allowing such management
> to be done by any client with the necessary credentials. I find this
> much more appealing than extending mgmt or rabbitmqctl.

I really wouldn't. I don't think the model should be adulterated with 
operational concerns (that's why, for instance, the "durable" flag is daft).

What I wouldn't mind is if there was management interface encoded in 
AMQP.  There's sort of provision already there for it, in the system 
exchange type.  Qpid has a whole framework (QMF) based on this approach, 
though I think it rather too keen to be generic.

> It's interesting how the "semantic equiv check" on queue.declare (in the
> case of redeclaring) should almost certainly _not_ care about such
> mutable aspects of queues.

Yes, good observation. In fact I'd say that anything that appears in the 
fields or arguments that doesn't seem like it should be part of that 
equivalence check, ought not to be in the arguments. ("Durable" fails 
this test, for example)

-M