On Tue, Jun 26, 2012 at 10:52 AM, Gordon Sim <[email protected]> wrote: > On 06/26/2012 03:46 PM, Alan Conway wrote: >> >> On 06/22/2012 10:51 AM, Gordon Sim wrote: >>> >>> On 06/22/2012 03:08 PM, Rajith Attapattu wrote: >>>> >>>> it's impossible to retain backwards compatibility while strictly >>>> adhering to the C++/python syntax. >>> >>> >>> I don't think that is true, but it depends on what exactly you mean by >>> the >>> 'c++/python syntax'. If it is really just the pseudo-python used to >>> describe >>> maps and can include lists and nested maps then to describe the existing >>> connection[1] url options you might have e.g. >>> >>> >>> {user:x,password:y,clientid:z,virtualhost:a,failover:b,maxprefetch:c,brokerlist:[{url:'host1:port1',retries:2,connectdelay:10},{url:'host2:port2',retries:3,connectdelay:5}]} >>> >>> >> >> From http://www.ietf.org/rfc/rfc2396.txt: >> >> Other characters are excluded because gateways and other transport >> agents are known to sometimes modify such characters, or they are >> used as delimiters. >> >> unwise = "{" | "}" | "|" | "\" | "^" | "[" | "]" | "`" >> >> So the {foo:bar} notation does not work well as part of a URL. > > > Right, but this is not a url, its a map of options in the python syntax that > was offered as being equivalent to those currently available in the JMS > 'Connection URL' in order to refute the statement that this was not > possible.
Further to what Gordon already mentioned, I wouldn't call the entire thing a URL, rather lets call it a connection string. It contains a URL and a set of options in the python map format. The URL should adhere to the given standard. Rajith > > --------------------------------------------------------------------- > 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]
