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 16:05:18 GMT
On 14 May 2014 21:48, Rob Godfrey <rob.j.godfrey@gmail.com> wrote:

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

Agreed.

The main thing I'd like is that you can pick out certain general bits of
info you might want to display on their own, like an overall product name
and version, without having to display all the other properties because you
couldn't easily separate them from the items of interest.


> 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