On 14 May 2014 02:23, Robbie Gemmell <[email protected]> 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 <[email protected]> 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 >
