You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Alan Conway <ac...@redhat.com> on 2010/03/16 14:09:04 UTC
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 Conway<ac...@redhat.com> wrote:
>> On 03/12/2010 10:40 AM, Rajith Attapattu wrote:
>>>
>>> On Fri, Mar 12, 2010 at 8:59 AM, Alan Conway<ac...@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-subscribe@qpid.apache.org
Re: URL-friendly address syntax [ was Re: Client configuration &
Connection URL]
Posted by Rajith Attapattu <ra...@gmail.com>.
On Fri, Mar 19, 2010 at 11:08 AM, Gordon Sim <gs...@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-subscribe@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-subscribe@qpid.apache.org
Re: URL-friendly address syntax [ was Re: Client configuration &
Connection URL]
Posted by Gordon Sim <gs...@redhat.com>.
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++.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: URL-friendly address syntax [ was Re: Client configuration &
Connection URL]
Posted by Alan Conway <ac...@redhat.com>.
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 Conway<ac...@redhat.com> wrote:
>>>> On 03/12/2010 10:40 AM, Rajith Attapattu wrote:
>>>>>
>>>>> On Fri, Mar 12, 2010 at 8:59 AM, Alan Conway<ac...@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.
>
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-subscribe@qpid.apache.org
Re: URL-friendly address syntax [ was Re: Client configuration &
Connection URL]
Posted by Rafael Schloming <ra...@redhat.com>.
Alan Conway wrote:
> On 03/15/2010 01:53 PM, Rajith Attapattu wrote:
>> On Mon, Mar 15, 2010 at 8:24 AM, Alan Conway<ac...@redhat.com> wrote:
>>> On 03/12/2010 10:40 AM, Rajith Attapattu wrote:
>>>>
>>>> On Fri, Mar 12, 2010 at 8:59 AM, Alan Conway<ac...@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-subscribe@qpid.apache.org