Sounds like a good idea to me. I have been meaning to do the same thing with some other properties like 'version' and 'product'.
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' :) Robbie On 13 May 2014 16:20, Gordon Sim <[email protected]> wrote: > The qpid::messaging (c++), qpid.messaging (python) libraries send > connection properties to identify the process by name and pid among other > things. These are then used by the QMF support in qpidd to report the > process details for the connections. > > This has proven to be an extremely useful feature and is supported also > over AMQP 1.0. At present the property names used for both 0-10 and 1.0 are > qpid.client_pid and qpid.client_process. > > However I would like to send this data in an application outside of > qpid[1]. Having standard names for these two items over AMQP 1.0 would be > great. This is not to force any implementation that doesn't support or > recognise them to do so, merely to encourage anyone adding something > similar to use the same property name for better interoperability. > > I'm open to any suggestions on the names to use, but I would like to > submit a request to OASIS to have them added to http://www.amqp.org/ > specification/1.0/connection-properties. My suggestion is simply to use > 'pid' and 'process'. > > Anyone have an opinion on this? If not I'll go ahead and send a request to > https://lists.oasis-open.org/archives/amqp-comment/ > > Apologies for the cross-posting, but I figured there may be interest on > the ActiveMQ side as well. > > --Gordon. > > [1] Specifically a proposed 'driver' supporting AMQP 1.0 in OpenStack's > messaging library: https://github.com/FlaPer87/oslo.messaging/tree/gordon > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
