Hey, i've not had much time to read this in detail, but there are two thoughts i have. Firstly if this is supposed to be url-like, should we aim for RESTyness if not actually RESTful at this juncture (because you have two bits, the connection and the destination)? Secondly, if it isn't supposed to be a url, did you think about using properties for each attribute? That might be a bit more natural for people, especially if they are pulling from non-properties sources like LDAP.
On 4/29/09, Rajith Attapattu <rajit...@gmail.com> wrote: > Hi All, > > I have prototyped a new configuration for the JMS Destination > abstraction, that addresses some of the issues associated with our > previous binding URL format. > > The proposal is organized as follows. > 1. Design concepts/notes > 2. Configuration format with examples > 3. Complete list of options available > 4. Code patch (attached with email) > > The proposal is located at, > > http://cwiki.apache.org/confluence/display/qpid/Proposal+for+a+new+JMS > +Destination+configuration > > Suggestions and criticisms are equally welcomed. > > > 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 > > -- Sent from Google Mail for mobile | mobile.google.com Apache Qpid - Give me convenience or give me death http://qpid.apache.org --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
