On 03/15/2010 01:53 PM, Rajith Attapattu wrote:
On Mon, Mar 15, 2010 at 8:24 AM, Alan Conway<acon...@redhat.com> wrote:
On 03/12/2010 10:40 AM, Rajith Attapattu wrote:
On Fri, Mar 12, 2010 at 8:59 AM, Alan Conway<acon...@redhat.com> wrote:
On 03/11/2010 06:41 PM, 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} ..."
I think there is value in keeping to a URL-friendly
Could you please elaborate on this?
I mean avoiding characters that are not allowed in URLs, in particular
spaces which are troublesome in a variety of contexts. However I if the
spaces are optional (I think they are given that there are always other
separators involved ,:{} then that may not be an issue.
Alan I think we should treat the "Broker" portion of it as a URL and
the key : value pairs separately.
IMO opinion they are two distinct entities that should be treated separately.
1. You need a URL parser to parse the broker part, migth as well use it for the
whole thing.
2. You're going to want to pass these strings around by various means outside of
qpid (filesystem, program arguments, web pages, other XML docs...) URL strings
are well known and easy to pass around. Strings with custom syntax and embedded
spaces will pose a variety of problems - you'll end up having to use some form
of quoting, URL syntax provides this for you.
I'll go one step further and suggest that we should use the standard
query-string syntax for name/value pairs:
tcp://localhost:8672/?ssl=true&sasl-mech=EXTERNAL&ssl-trust-store=~/cert.jks ...
Every URL parser out there already knows how to parse this.
I'll go another step further and propose that we modify the new address string
format to be URL friendly.
I see 2 issues: spaces and ';'
I think spaces is a non issue as you can just leave them out - am I correct on
that?
The issue with ';' is that URLs use it as a separator (alternative to '&') in
the query string. I suggest we simply drop it. Then we can easily embed
addresses in URLS, e.g.
tcp://localhost:8672/?ssl=true;sasl-mech=EXTERNAL;address=myqueue{create:always,node-properties:{durable:true}}
...
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
