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