>>
>> I was thinking the format for specifying queue properties would be
>> standard across languages regardless of whether the queue declaration is
>> separate or nested.
>>
>> If you're talking about something like this:
>>
>> dest.D = MyQueue; {auto-create=true, queue-definition={durable=true, ...},
>> ...}
>>
>> or even this:
>>
>> dest.D = MyQueue; {auto-create={durable=true, ...}, ...}
>
> I particularly like this second version.
>
>> then I don't really care whether the queue definition is separate or not.
>>
>> I would prefer to avoid something like this though where the queue options
>> are mixed together with the consumer/producer options:
>>
>> dest.D = MyQueue; {exclusive=true, prefetch=100, auto-delete=true, ...}
>
> Yes, I understand and agree on that point. It would get too confusing that
> way.
>
I think we need clarity about whether we are defining a format for
*JMSDestination* or for some other AMQP abstraction of
consumer/producer/link.
The JMS definition is quite clear that the destination represents only
the address ("A Destination object encapsulates a provider-specific
address") - therefore properties of queues, etc should not form part
of its definition. In particular consider the case where you use
setReplyTo(JMSDestination) ... the *only* information that is
actually sent over the wire is (correctly) the address.
In the case above. if you use
dest.D = MyQueue; {auto-create={durable=true, ...}, ...}
as a destination for ReplyTo then the receiver of the message will
have to create the destination as the equivalent of
dest.D = MyQueue
The receiving client will not hear that it is supposed to create the
queue and make it durable.
JMS further mandates that the destination you receive on your incoming
message should have equality with the original address as set. This
means that *only* the address can be examined in .equals() tests...,
hashCode(), etc... Therefore making queue properties part of the
JMSDestination seems to be somewhat misleading.
If we were discussing the configuration for AMQP 1-0 style links then
I would completely agree that having everything on the one line would
make sense...
For JMSDestinations I am more opposed.
-- Rob
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
