qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robbie Gemmell <robbie.gemm...@gmail.com>
Subject Re: AMQP 1.0 connection property names
Date Thu, 15 May 2014 15:44:18 GMT
On 14 May 2014 17:54, Gordon Sim <gsim@redhat.com> wrote:

> On 05/14/2014 10:23 AM, Robbie Gemmell wrote:
>> My interest is mostly around conveying the main component being doing the
>> messaging (e.g. Qpid Messaging C++ Client, ActiveMQ Broker) rather than
>> the
>> application, but I can see that could be useful too in some cases.
> Yes, and I don't want to overcomplicate things. In some cases 'product'
> might be a little ambiguous is all.
>  Making product be a map of name:version entries would certainly allow
>> conveying more information, but could also make it harder to use the
>> information for anything except blind display, as you would need a clearer
>> idea in advance of what is going to be there to do much else with it given
>> each 'aggregate product' could convey different things and may even end up
>> giving different map key names to the same effective sub-component (e.g
>> they might say proton-engine, or perhaps just proton).
> Agreed.
>  That said, I imagine that kind of thing could be an issue anyway whether
>> it
>> was a map or just a simple value because it ultimately depends on if/how
>> the information is populated in the first place.
> Related to that, would a separate version be needed, or could that be
> included in the product? The main case I can think of where you might want
> programmatic access to this is in choosing (hopefully temporary!)
> workarounds for different interop issues.
The main reason I was looking to pick 'product' and 'version' was for the
historical consistency (theyve been defined that way since at least 0-8),
and then partly just based on how we currently use them in the Java broker
by sending them to the client, and explicitly logging the clients
product+version along with some other things for new connections. I have no
real issue with combining their values.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message