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 Wed, 14 May 2014 09:23:53 GMT
Now that Gordons email has arrived for me, I'll reply to the rest of it :)

On 13 May 2014 17:31, Gordon Sim <gsim@redhat.com> wrote:

> On 05/13/2014 04:47 PM, Robbie Gemmell wrote:
>> Sounds like a good idea to me. I have been meaning to do the same thing
>> with some other properties like 'version' and 'product'.
> Yeah, my one question there was about distinguishing different 'layers'.
> E.g. proton engine version, v. qpid::messaging version, v. some application
> version. Maybe product should be a list or map? Or maybe the key should be
> the product name and the value the version?
> I don't have particularly strong feelings though I agree some standards
> here could be useful.
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.

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).

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.

>  My only comment around the actual names is that 'process' doesnt
>> immediately make me think 'name' and even seems a little like it could be
>> describing the same thing as 'pid' if you didnt know both properties
>> existed, which I have always thought about the older versions too. That
>> isn't to say I necessarily have a good alternative suggestion, the only
>> short one I could think of was 'pname' :)
> How about process_name and process_id then?
As per previous reply to Justin, those would be fine with me (as would pid
and pname)


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