On Fri, Mar 19, 2010 at 8:23 AM, Rafael Schloming <[email protected]> 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:[email protected]
>>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:[email protected]
>
>
--
Regards,
Rajith Attapattu
Red Hat
http://rajith.2rlabs.com/
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
