activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Godfrey <rob.j.godf...@gmail.com>
Subject Re: AMQP 1.0 connection property names
Date Wed, 14 May 2014 20:48:54 GMT
On 14 May 2014 02:23, Robbie Gemmell <robbie.gemmell@gmail.com> wrote:

> 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).
>
>
So, I'd hope that any such information would be purely informational (for
display) rather than any client/service embedding logic based on the client
(library) in use.  Where we need to indicate/detect behaviours relating to
clients/brokers these should be defined in unambiguous behavioural
connection properties.

In terms of the purely informational "process id", "process name" style
attributes, I was initially going to suggest a map, but then really that is
only just moving the issue down one level.  I think process[-_ ]id and
process[-_ ]name make sense as defined properties -  have a well defined
meaning in the context of the operating system on which the peer is
running.

For indicating the use of proton I'd suggest we define a
qpid-proton-version property or some such (and then a
qpid-messaging-version / qpid-jms-version / whatever) - i.e. each layer of
"library" might add it's own connection properties to indicate its presence
/ version.


> 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 above - those work for me... If we're getting close to agreeing on
these, we should probably cross post to the amqp comments list.

-- Rob

>
> >
> As per previous reply to Justin, those would be fine with me (as would pid
> and pname)
>
> Robbie
>

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