On Fri, Jun 22, 2012 at 11:26 AM, Gordon Sim <[email protected]> wrote: > On 06/22/2012 04:07 PM, Rajith Attapattu wrote: >> >> I was actually thinking about a common set of property names >> across all clients (rather than allow existing connection URL stuff to >> be used this way). > > > Earlier you said answered that you were proposing "new syntax for expressing > the existing options". No issue with changing your mind, I'm just trying to > nail down what exactly it is you are proposing.
My bad for not being clear with my language. If it did gave the above impression, I sincerely apologize. What I wanted to convey was, that I wanted to support existing functionality in the JMS URL, not exactly the property names. If people are going to use the new syntax, then they should use the prop names that is common to all clients. And I think Ken's approach could support the existing functionality of our Connection URL with multiple brokers with their own property values, than the approaches we both suggested. Is it clear now what I'm trying to get at? Rajith > >> If somebody wants to use an existing ConnectionURL as it is, then we >> can parse it an populate a data structure internally that makes more >> sense, rather than trying to convert it first to a string like this. > > > The structure of options for the current connection URL is not the same as > the structure of options for the c++ and python clients though. That was the > point of my first mail. (Your solution seemed to be a revised connection > string syntax). > > >> If somebody wants to write it with the new syntax then they could use >> the same props we use for the other languages. > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
