The proposed scheme was effectively assuming that we should be able to specify client properties per broker. If we all agree that this is useless to do that then we should stay with the amqp format. If we think that it could be useful to specify some properties on a per broker basis then my proposal makes kind of sense. We could also use a combination of both approaches if we want to allow setting properties globally and locally. This being said I thought that we were not allowed to use the name amqp for our URL. This is why I changed it to qpid. Robert can you clarify that point please?
Thanks Arnaud On Tue, 2007-08-21 at 14:52 +0100, Martin Ritchie wrote: > On 21/08/07, Robert Godfrey <[EMAIL PROTECTED]> wrote: > > Agreed... sticking to the amqp format would be great > > > > that would give us something that looked like: > > > > amqp:tcp:host.domain.com:5672/virtualhost=test;username=guest;password=guest > > > > which does look tidier to me, > > > > Thoughts from others? > > > > -- Rob > > > > On 21/08/07, Robert Greig <[EMAIL PROTECTED]> wrote: > > > > > > On 21/08/07, Arnaud Simon <[EMAIL PROTECTED]> wrote: > > > > > > > > What do you think about this scheme? > > > > > > Looks fine but I have one question: why have client_opts at the start? > > > Why not include them at the end as part of future_parameters? Putting > > > them at the start would only be necessary if we had a hierarchical > > > URL. > > > > > > If we did that would we need to deviate from the amqp:// format? > > > > > > RG > > > > > I think it makes sense to extend the currently proposed 0_10 spec > rather than trying to augment it as a qpid only URL. We'll have to be > able to parse the 0_10 format so makes sense to just add the client > args to the end. > > I think the likelihood of having more than one host on the URL is low. > In the circumstances where more than 1 broker exists the likelihood of > using different connection mechanisms is low. So being able to prepped > special client config per broker is low. In failover the client is > informed of other client connectivity options. > > Regards
