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.
The Connection **String** is just a convenient way of expressing them together.
The broker part is to figure out where the broker is and the latter is
to configure the client options, but scoped by the given connection.
I really don't see any advantage in treating the whole string as a URL.
Perhaps I missed something?
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
