Re: URL-friendly address syntax [ was Re: Client configuration Connection URL]
Alan Conway wrote:
On 03/15/2010 01:53 PM, Rajith Attapattu wrote:
On Mon, Mar 15, 2010 at 8:24 AM, Alan Conwayacon...@redhat.com wrote:
On 03/12/2010 10:40 AM, Rajith Attapattu wrote:
On Fri, Mar 12, 2010 at 8:59 AM, Alan Conwayacon...@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=truesasl-mech=EXTERNALssl-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
Re: URL-friendly address syntax [ was Re: Client configuration Connection URL]
On 03/19/2010 07:42 AM, Rafael Schloming wrote:
Alan Conway wrote:
On 03/15/2010 01:53 PM, Rajith Attapattu wrote:
On Mon, Mar 15, 2010 at 8:24 AM, Alan Conwayacon...@redhat.com wrote:
On 03/12/2010 10:40 AM, Rajith Attapattu wrote:
On Fri, Mar 12, 2010 at 8:59 AM, Alan Conwayacon...@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=truesasl-mech=EXTERNALssl-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.
You can nest any string in a URL by using the standard URL quoting. It's nicer
though, if you don't have to quote.
URLs are a widely accepted format for addressing and part of the AMQP 0-10
standard for addressing brokers, so I think it would be valuable to make it
easy for these strings to be included in URLs. I don't think there's a big
change needed, or that python dictionary syntax is something that we need to
stick to for a multi-language system like qpid.
-
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: URL-friendly address syntax [ was Re: Client configuration Connection URL]
On Fri, Mar 19, 2010 at 11:08 AM, Gordon Sim g...@redhat.com wrote: On 03/19/2010 02:57 PM, Alan Conway wrote: URLs are a widely accepted format for addressing and part of the AMQP 0-10 standard for addressing brokers, so I think it would be valuable to make it easy for these strings to be included in URLs. Does the currently defined URL scheme for AMQP 0-10 support options? It is certainly a different form from the example URls given in this thread and currently is only supported in c++. I don't know if it does as it was designed for a specific purpose. IIRC correctly the AMQP 0-10 format was introduced to provide the list of brokers through the failover exchange. All most all the options are client side configuration and don't need to be shipped around. We could use existing URL parsers if we somehow shoehorn the connection string into a URL format. But I'd argue the issues surrounding the current Java URL connection format far outweighed those benefits. - 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
URL-friendly address syntax [ was Re: Client configuration Connection URL]
On 03/15/2010 01:53 PM, Rajith Attapattu wrote:
On Mon, Mar 15, 2010 at 8:24 AM, Alan Conwayacon...@redhat.com wrote:
On 03/12/2010 10:40 AM, Rajith Attapattu wrote:
On Fri, Mar 12, 2010 at 8:59 AM, Alan Conwayacon...@redhat.comwrote:
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=truesasl-mech=EXTERNALssl-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
