On Fri, Mar 19, 2010 at 8:23 AM, Rafael Schloming <rafa...@redhat.com> wrote: > I think the first step we need to take before actually thinking about the > syntax is to put together a matrix with all the connection parameters for > all the clients. > > Historically we've picked a common syntax (URL) but not really bothered to > ensure that we use the syntax the same way. This is in part because the > different clients support different options or different ways of > semantically expressing the same option, so I think the first step is to > actually align the semantics of the different client connection options so > that there is actually some benefit to using the same syntax. > > Also, I think once we do that it will be easier to see what the requirements > for the syntax are and whether URL or something more expressive is a better > fit. > > I'm actually futzing with a few of the connection options for the python > client now, but when I finish with that I'll post a complete list for the > python client.
+1 I think it's a very sensible step to first figure out the requirements for each client. I will create a wiki page and add the Java client stuff. Regards, Rajith > --Rafael > > Rajith Attapattu wrote: >> >> Hi All, >> >> Currently quite a bit of options can be configured via the Java >> Connection URL, which tends to make it ungainly and quite error prone. >> If we are to think in terms of a "Connection String" instead of a >> "Connection URL" , then I believe we could come up with a more simpler >> solution. >> >> Therefore I'd like to make the following proposals. >> >> 1) Introduce a simple scheme for a "Connection String" ( inspired by >> the new addressing format) >> 2) Also allow the ability to specify the config using a property file. >> >> * I hate having to specify user/pass when the auth mech (ex kerberos) >> is not even using it. Therefore it should be optional ! >> >> 1. 0 Connection String >> --------------------------- >> 1.1 Examples >> "tcp://localhost" >> "tcp://localhost:8672; {ssl: true, sasl-mech : EXTERNAL, >> ssl-trust-store : ~/cert.jks ..} " >> "tcp://host1.example.com; {user: bob, pass: nuts} , >> tcp://host2.example.com; {user: ding, pass: dong} ..." >> >> 1.2 Syntax >> <broker> [ ; <options> ] [ , <broker> [ ; <options> ]] * >> >> Where broker is:: >> <protocol>:// [ host [ ":" port ] ] (protocol = {tcp|vm|rdma} >> >> Where options is:: >> >> { <key> : <value>, ... } >> >> And values may be: >> - numbers >> - single, double, or non quoted strings >> - maps (dictionaries) >> - lists >> >> >> 2.0 Config file >> ----------------- >> Example >> >> JNDI prop file >> connection.my-connection = "tcp://localhost; {id : 1}" >> connection.my-con = "tcp://host1.example.com; {id: 2} , >> tcp://host2.example.com; {id: 2}, tcp://host3.example.com; {id: 3}" >> >> =========Connection.properties========= >> con id : 1 { >> ssl: true >> sasl-mech : EXTERNAL >> ssl-trust-store : ~/cert.jks >> ssl-key-store : ~/keys.jks >> ssl-verify-hostname : true >> } >> >> con id : 1 { >> sasl-mech : GSSAPI >> sasl-hostname : host1.example.com >> sasl-protocol : qpidd >> sasl-encryption : true >> tcp-nodelay : true >> } >> >> >> con id : 3 { >> user : ding >> pass : dong >> tcp-nodelay : true >> } >> >> ================================== >> >> Connection.properties can be loaded from the classpath or specified as >> an option in the connection string. >> (You could also trivially have a connection property file per connection). >> >> Comments and suggestions are most 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 >> > > --------------------------------------------------------------------- > 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