Alan Conway wrote:
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}}
...
I don't think we can really remove the ';'. The name/subject part of the
address can include fairly complex patterns that include curly braces,
so we really need something to separate the options from the address,
and ';' is pretty much the only reasonable option for this given the
syntax for what goes on either side.
The address syntax was specifically chosen because the URL syntax is
insufficiently powerful to be able to reasonably express everything that
needs to be able to go into an address, things like nested maps/lists,
embedded selector strings, etc. The address syntax is pretty much a pure
subset of python dictionary syntax, so it's always going to be more
expressive than what will be able to naturally fit in a URL.
Personally I think if we nest it's more natural to do it the other way
around. Nest the more limited syntax inside the more powerful one. This
is trivial: {url: "foo://bar.baz.qux"}. You're always going to have
problems if you try to nest the other way around.
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
