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, ...}
As I understand it you would only add options to the destination in
order to configure the individual producers and consumers created from
the destination, e.g.:
destinationx.my-jndi-name = MyQueue; {prefetch=100, sync=true, ...}
The advantage as I viewed it was more related to intuitiveness (since
the file is a properties file).
I think most destination definitions will be quite simple and may not
be as confusing with the more compact format.
I don't think the compact syntax is confusing; I think its just
another syntax embedded in the properties file syntax. I could
certainly live with that, but it's probably worth thinking about it
and being sure that the reasons for it are clear.
I think the source of confusion may be around the various options,
what they mean, how they are interpreted or whether they are valid in
a given context or not.
I think the main reason for using this format rather than a flat
properties file format is that we also need a syntax for something
people can pass to Session.createTopic("...") and
Session.createQueue("..."), and the properties file format doesn't
work so well for that.
Thats a fair point (at least to an extent!).
I think there are some other good reasons to avoid depending too heavily
on the properties file format for the syntax of the destination. 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).
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.
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
