Rafael Schloming wrote:
Gordon Sim wrote:
Rafael Schloming wrote:
Gordon Sim wrote:
Rajith Attapattu wrote:
Gordon,
Thanks for you feedback. Comments inline.
On Tue, May 5, 2009 at 2:06 PM, Gordon Sim <g...@redhat.com> wrote:
Suggestions and criticisms are equally welcomed.
I am very much in favour of some changes in the configuration of
destinations and expanding the capabilities in this regard.
However I wonder
if perhaps a simpler syntax is possible?
Even the simplest example:
xqueue.myQueue = name='myQueue'
xdestination.myQueue = queue=myQueue
Could you compare with new proposal I sent to the list and see if the
simplest format is good enough?
In the new one it would be as simple as
destinationx.<jndi-name> = myQueue
So are the following entirely independent and equivalent forms for
the same thing?
queuex.my-jndi-name = {name=MyQueue, durable=true}
destinationx.my-jndi-queue = MyQueue; {durable=true}
If so, whats the motivation for the first form?
I think the queuex stuff is only to control whether and how you
auto-declare queues, so the common case would be:
destinationx.my-jndi-name = MyQueue
And then if you wanted to auto-declare the queue you would add this:
queuex.MyQueue = {auto-create=true, durable=true, ...}
I see. That is not at all obvious (at least to me) from either the
syntax or the proposal text.
Is the auto-create not implied in that case? I.e. why else would you
have a queuex type declaration other than to auto-create the queue?
I presume it would be to make assertions on the properties of a queue,
however you could choose to omit that feature and imply auto-create from
the presence of the declaration.
Would such a queue be auto-created for either the first consumer or
the first producer to be created?
I think you might actually want to control that explicitly, e.g. have
something like this:
queuex.MyQueue = {create-on-send=true, create-on-receive=false, ...}
Why could you not do this on a 'destinationx'? That would seem much
neater to me.
I think there are some other good reasons to avoid depending too heavily
on the properties file format for the syntax of the destination.
I sort of view it the other way round, i.e. you are using a properties
file syntax to configure a destination, not defining a universal syntax
for destinations. However...
In
particular for consistent configuration across varied file formats
(including across the various different language clients), it is fairly
nice to have a closed and self-contained syntax for specifying addresses
and configuring links (producers & consumers).
That objective I agree with, and given that I also agree that format is
a fair choice as the value of the property in a properties file.
I would ideally like to be able to cut and paste this part of the
configuration between a java, cpp, and python client, or even between a
.properties jndi file and, e.g. a .xml jndi file. I don't see this
happening if we design the syntax specifically for a flat properties file.
Yes, I agree with that also.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
