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?
seems a little unintuitive and awkward to me. Is the 'x' important? Is it to
avoid clashing with existing formats?
Yes.
Could we instead specify a different class as the value for
java.naming.factory.initial (i.e. one that supported
a different syntax)?
That was my first option. But for existing systems if they want to use
a mix of both formats this approach may not work.
Why would someone want to use a mix of formats?
Also it maybe potentially confusing.
In what way?
However I am ok with either
option. I will go with what the majority likes.
Thinking aloud, my ideal syntax would be something along the lines of:
my-queue.type=org.apache.qpid.client.AMQQueue
I think a single destination impl should be able to handle any type
and I demonstrated that in the patch with AMQXDestination class.
We currently have a destination impl per exchange and I think that
restricts flexibility and IMO this sort of specialization is
unnecessary.
For example can't use amq.topic destination with a named queue and the
current AMQHeadersExchange class doesn't provide any useful function.
However I agree that this maybe a good extension point. Where someone
could provide a specialized implementation of the destination impl.
But given how the current design around this there isn't much you
could achieve with this.
Fair enough.
But since the format I proposed is extensible this can be added at anytime.
my-queue.name=abc
my-queue.publisher.sync=true
my-queue.subscriber.prefetch=100
etc. etc.
It seems that you also prefer the same syntax as Aidan.
My only gripe with this is that it is quite verbose. But the advantage
is you don't need to write a parser (as Aidan pointed out).
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.
What we could do is to have a different IntialContextImpls where one
would deal with the compact form and another one for folks who like
the more verbose format.
I'd avoid multiple options unless absolutely necessary.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
