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 > 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. Also it maybe potentially confusing. 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. 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). I think most destination definitions will be quite simple and may not be as confusing with the more compact format. 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 haven't thought through all the requirements or the impact on > implementation complexity of course. The above may not be feasible; I'm > merely including it as a half-baked comment on ways that the syntax might be > made a little simpler for the user. > > > --------------------------------------------------------------------- > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:dev-subscr...@qpid.apache.org > > -- Regards, Rajith Attapattu Red Hat http://rajith.2rlabs.com/ --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
