You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by Gordon Sim <gs...@redhat.com> on 2014/05/13 17:20:57 UTC
AMQP 1.0 connection property names
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: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: AMQP 1.0 connection property names
Posted by Robbie Gemmell <ro...@gmail.com>.
On 13 May 2014 20:04, Gordon Sim <gs...@redhat.com> wrote:
> On 05/13/2014 05:12 PM, Chuck Rolke wrote:
>
>> I like having registered properties especially for common cases.
>>
>> 'client-pid' and 'client-name' would be my first vote.
>>
>
> The reason I don't like 'client' in there is that its not always 'clients'
> making the connection and further, 'client' means different things in
> different contexts. E.g. in an RPC over messaging situation the 'client' is
> the process making the requests, the 'server' the one responding, though
> from a brokers point of view both are clients.
>
>
Agreed, it would be good to keep description of the 'process type' out of
the names to avoid ambiguity and reduce the temptation in future to create
alternate properties conveying the same information.
>
> 'pid' and 'pname' second.
>> 'pid' and 'process' third.
>>
>
> I'm fine with any of these.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
Re: AMQP 1.0 connection property names
Posted by Robbie Gemmell <ro...@gmail.com>.
On 13 May 2014 20:04, Gordon Sim <gs...@redhat.com> wrote:
> On 05/13/2014 05:12 PM, Chuck Rolke wrote:
>
>> I like having registered properties especially for common cases.
>>
>> 'client-pid' and 'client-name' would be my first vote.
>>
>
> The reason I don't like 'client' in there is that its not always 'clients'
> making the connection and further, 'client' means different things in
> different contexts. E.g. in an RPC over messaging situation the 'client' is
> the process making the requests, the 'server' the one responding, though
> from a brokers point of view both are clients.
>
>
Agreed, it would be good to keep description of the 'process type' out of
the names to avoid ambiguity and reduce the temptation in future to create
alternate properties conveying the same information.
>
> 'pid' and 'pname' second.
>> 'pid' and 'process' third.
>>
>
> I'm fine with any of these.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
Re: AMQP 1.0 connection property names
Posted by Gordon Sim <gs...@redhat.com>.
On 05/13/2014 05:12 PM, Chuck Rolke wrote:
> I like having registered properties especially for common cases.
>
> 'client-pid' and 'client-name' would be my first vote.
The reason I don't like 'client' in there is that its not always
'clients' making the connection and further, 'client' means different
things in different contexts. E.g. in an RPC over messaging situation
the 'client' is the process making the requests, the 'server' the one
responding, though from a brokers point of view both are clients.
> 'pid' and 'pname' second.
> 'pid' and 'process' third.
I'm fine with any of these.
Re: AMQP 1.0 connection property names
Posted by Gordon Sim <gs...@redhat.com>.
On 05/13/2014 05:12 PM, Chuck Rolke wrote:
> I like having registered properties especially for common cases.
>
> 'client-pid' and 'client-name' would be my first vote.
The reason I don't like 'client' in there is that its not always
'clients' making the connection and further, 'client' means different
things in different contexts. E.g. in an RPC over messaging situation
the 'client' is the process making the requests, the 'server' the one
responding, though from a brokers point of view both are clients.
> 'pid' and 'pname' second.
> 'pid' and 'process' third.
I'm fine with any of these.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: AMQP 1.0 connection property names
Posted by Chuck Rolke <cr...@redhat.com>.
I like having registered properties especially for common cases.
'client-pid' and 'client-name' would be my first vote.
'pid' and 'pname' second.
'pid' and 'process' third.
-C
----- Original Message -----
> From: "Robbie Gemmell" <ro...@gmail.com>
> To: users@qpid.apache.org
> Cc: dev@activemq.apache.org
> Sent: Tuesday, May 13, 2014 11:47:30 AM
> Subject: Re: AMQP 1.0 connection property names
>
> 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 <gs...@redhat.com> 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: users-unsubscribe@qpid.apache.org
> > For additional commands, e-mail: users-help@qpid.apache.org
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: AMQP 1.0 connection property names
Posted by Justin Ross <jr...@apache.org>.
On Tue, May 13, 2014 at 3:25 PM, Robbie Gemmell <ro...@gmail.com>wrote:
>
> >
> > Out of curiosity, is there any interest in offering the command line (a
> la
> > "process_command_line")? The arguments passed to a process can often be
> > used to distinguish it from others quickly.
> >
>
> That might open up some issues, requiring consideration if anything on the
> command line needs sanitized.
>
You're right. We can't assume the information in the command line is safe
to put on the wire.
Re: AMQP 1.0 connection property names
Posted by Justin Ross <jr...@apache.org>.
On Tue, May 13, 2014 at 3:25 PM, Robbie Gemmell <ro...@gmail.com>wrote:
>
> >
> > Out of curiosity, is there any interest in offering the command line (a
> la
> > "process_command_line")? The arguments passed to a process can often be
> > used to distinguish it from others quickly.
> >
>
> That might open up some issues, requiring consideration if anything on the
> command line needs sanitized.
>
You're right. We can't assume the information in the command line is safe
to put on the wire.
Re: AMQP 1.0 connection property names
Posted by Chuck Rolke <cr...@redhat.com>.
+1 Ship It!
----- Original Message -----
> From: "Gordon Sim" <gs...@redhat.com>
> To: users@qpid.apache.org
> Cc: dev@activemq.apache.org
> Sent: Wednesday, May 14, 2014 12:54:43 PM
> Subject: Re: AMQP 1.0 connection property names
>
> On 05/13/2014 08:25 PM, Robbie Gemmell wrote:
> > On 13 May 2014 17:59, Justin Ross <jr...@apache.org> wrote:
> >> On Tue, May 13, 2014 at 12:31 PM, Gordon Sim <gs...@redhat.com> wrote:
> >>> How about process_name and process_id then?
> >>
> >>
> >> I like those. I don't think brevity is important in this case, and those
> >> names are very clear to me.
> >>
> >
> > Works for me too.
>
> Ok, does anyone object to process_name and process_id?
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: AMQP 1.0 connection property names
Posted by Rafael Schloming <rh...@alum.mit.edu>.
I don't object, but one thing that strikes me as a little odd with the
original names was the use of both '.' and '_' as separators
(qpid.client_pid vs qpid.client.pid).
Now I don't know what conventions these names are supposed to follow, but
my best guess would be that '.' should be used for separating namespaces
and '_' for separating words in a compound phrase. In this case I can see
it both ways, but if you think there might be other process related things
in the future then it might be worth thinking of process as a namespace and
going with process.name and process.id.
--Rafael
On Wed, May 14, 2014 at 12:54 PM, Gordon Sim <gs...@redhat.com> wrote:
> On 05/13/2014 08:25 PM, Robbie Gemmell wrote:
>
>> On 13 May 2014 17:59, Justin Ross <jr...@apache.org> wrote:
>>
>>> On Tue, May 13, 2014 at 12:31 PM, Gordon Sim <gs...@redhat.com> wrote:
>>>
>>>> How about process_name and process_id then?
>>>>
>>>
>>>
>>> I like those. I don't think brevity is important in this case, and those
>>> names are very clear to me.
>>>
>>>
>> Works for me too.
>>
>
> Ok, does anyone object to process_name and process_id?
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
Re: AMQP 1.0 connection property names
Posted by Rafael Schloming <rh...@alum.mit.edu>.
I don't object, but one thing that strikes me as a little odd with the
original names was the use of both '.' and '_' as separators
(qpid.client_pid vs qpid.client.pid).
Now I don't know what conventions these names are supposed to follow, but
my best guess would be that '.' should be used for separating namespaces
and '_' for separating words in a compound phrase. In this case I can see
it both ways, but if you think there might be other process related things
in the future then it might be worth thinking of process as a namespace and
going with process.name and process.id.
--Rafael
On Wed, May 14, 2014 at 12:54 PM, Gordon Sim <gs...@redhat.com> wrote:
> On 05/13/2014 08:25 PM, Robbie Gemmell wrote:
>
>> On 13 May 2014 17:59, Justin Ross <jr...@apache.org> wrote:
>>
>>> On Tue, May 13, 2014 at 12:31 PM, Gordon Sim <gs...@redhat.com> wrote:
>>>
>>>> How about process_name and process_id then?
>>>>
>>>
>>>
>>> I like those. I don't think brevity is important in this case, and those
>>> names are very clear to me.
>>>
>>>
>> Works for me too.
>>
>
> Ok, does anyone object to process_name and process_id?
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
Re: AMQP 1.0 connection property names
Posted by Chuck Rolke <cr...@redhat.com>.
+1 Ship It!
----- Original Message -----
> From: "Gordon Sim" <gs...@redhat.com>
> To: users@qpid.apache.org
> Cc: dev@activemq.apache.org
> Sent: Wednesday, May 14, 2014 12:54:43 PM
> Subject: Re: AMQP 1.0 connection property names
>
> On 05/13/2014 08:25 PM, Robbie Gemmell wrote:
> > On 13 May 2014 17:59, Justin Ross <jr...@apache.org> wrote:
> >> On Tue, May 13, 2014 at 12:31 PM, Gordon Sim <gs...@redhat.com> wrote:
> >>> How about process_name and process_id then?
> >>
> >>
> >> I like those. I don't think brevity is important in this case, and those
> >> names are very clear to me.
> >>
> >
> > Works for me too.
>
> Ok, does anyone object to process_name and process_id?
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
Re: AMQP 1.0 connection property names
Posted by Gordon Sim <gs...@redhat.com>.
On 05/13/2014 08:25 PM, Robbie Gemmell wrote:
> On 13 May 2014 17:59, Justin Ross <jr...@apache.org> wrote:
>> On Tue, May 13, 2014 at 12:31 PM, Gordon Sim <gs...@redhat.com> wrote:
>>> How about process_name and process_id then?
>>
>>
>> I like those. I don't think brevity is important in this case, and those
>> names are very clear to me.
>>
>
> Works for me too.
Ok, does anyone object to process_name and process_id?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: AMQP 1.0 connection property names
Posted by Gordon Sim <gs...@redhat.com>.
On 05/13/2014 08:25 PM, Robbie Gemmell wrote:
> On 13 May 2014 17:59, Justin Ross <jr...@apache.org> wrote:
>> On Tue, May 13, 2014 at 12:31 PM, Gordon Sim <gs...@redhat.com> wrote:
>>> How about process_name and process_id then?
>>
>>
>> I like those. I don't think brevity is important in this case, and those
>> names are very clear to me.
>>
>
> Works for me too.
Ok, does anyone object to process_name and process_id?
Re: AMQP 1.0 connection property names
Posted by Robbie Gemmell <ro...@gmail.com>.
Sending again, this time remembering to hit reply-all to keep both lists as
recipients...
On 13 May 2014 17:59, Justin Ross <jr...@apache.org> wrote:
> On Tue, May 13, 2014 at 12:31 PM, Gordon Sim <gs...@redhat.com> wrote:
> >
> > 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?
>
>
> I like those. I don't think brevity is important in this case, and those
> names are very clear to me.
>
Works for me too.
(replying to Justin's mail because I haven't received Gordon's one yet!)
>
> Out of curiosity, is there any interest in offering the command line (a la
> "process_command_line")? The arguments passed to a process can often be
> used to distinguish it from others quickly.
>
That might open up some issues, requiring consideration if anything on the
command line needs sanitized.
Re: AMQP 1.0 connection property names
Posted by Robbie Gemmell <ro...@gmail.com>.
Sending again, this time remembering to hit reply-all to keep both lists as
recipients...
On 13 May 2014 17:59, Justin Ross <jr...@apache.org> wrote:
> On Tue, May 13, 2014 at 12:31 PM, Gordon Sim <gs...@redhat.com> wrote:
> >
> > 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?
>
>
> I like those. I don't think brevity is important in this case, and those
> names are very clear to me.
>
Works for me too.
(replying to Justin's mail because I haven't received Gordon's one yet!)
>
> Out of curiosity, is there any interest in offering the command line (a la
> "process_command_line")? The arguments passed to a process can often be
> used to distinguish it from others quickly.
>
That might open up some issues, requiring consideration if anything on the
command line needs sanitized.
Re: AMQP 1.0 connection property names
Posted by Robbie Gemmell <ro...@gmail.com>.
On 13 May 2014 17:59, Justin Ross <jr...@apache.org> wrote:
> On Tue, May 13, 2014 at 12:31 PM, Gordon Sim <gs...@redhat.com> wrote:
> >
> > 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?
>
>
> I like those. I don't think brevity is important in this case, and those
> names are very clear to me.
>
Works for me too.
(replying to Justin's mail because I haven't received Gordon's one yet!)
> Out of curiosity, is there any interest in offering the command line (a la
> "process_command_line")? The arguments passed to a process can often be
> used to distinguish it from others quickly.
>
That might open up some issues, requiring consideration if anything on the
command line needs sanitized.
Re: AMQP 1.0 connection property names
Posted by Justin Ross <jr...@apache.org>.
On Tue, May 13, 2014 at 12:31 PM, Gordon Sim <gs...@redhat.com> wrote:
>
> 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?
I like those. I don't think brevity is important in this case, and those
names are very clear to me.
Out of curiosity, is there any interest in offering the command line (a la
"process_command_line")? The arguments passed to a process can often be
used to distinguish it from others quickly.
Re: AMQP 1.0 connection property names
Posted by Gordon Sim <gs...@redhat.com>.
On 05/14/2014 09:48 PM, Rob Godfrey wrote:
> On 14 May 2014 02:23, Robbie Gemmell <ro...@gmail.com> wrote:
>> On 13 May 2014 17:31, Gordon Sim <gs...@redhat.com> wrote:
[...]
> 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.
I like that.
[...]
>>> 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.
Ok, I'll submit a request for these two.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: AMQP 1.0 connection property names
Posted by Robbie Gemmell <ro...@gmail.com>.
On 14 May 2014 21:48, Rob Godfrey <ro...@gmail.com> wrote:
> On 14 May 2014 02:23, Robbie Gemmell <ro...@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 <gs...@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
> >
>
Re: AMQP 1.0 connection property names
Posted by Robbie Gemmell <ro...@gmail.com>.
On 14 May 2014 21:48, Rob Godfrey <ro...@gmail.com> wrote:
> On 14 May 2014 02:23, Robbie Gemmell <ro...@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 <gs...@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
> >
>
Re: AMQP 1.0 connection property names
Posted by Gordon Sim <gs...@redhat.com>.
On 05/14/2014 09:48 PM, Rob Godfrey wrote:
> On 14 May 2014 02:23, Robbie Gemmell <ro...@gmail.com> wrote:
>> On 13 May 2014 17:31, Gordon Sim <gs...@redhat.com> wrote:
[...]
> 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.
I like that.
[...]
>>> 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.
Ok, I'll submit a request for these two.
Re: AMQP 1.0 connection property names
Posted by Rob Godfrey <ro...@gmail.com>.
On 14 May 2014 02:23, Robbie Gemmell <ro...@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 <gs...@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
>
Re: AMQP 1.0 connection property names
Posted by Robbie Gemmell <ro...@gmail.com>.
On 14 May 2014 17:54, Gordon Sim <gs...@redhat.com> wrote:
> On 05/14/2014 10:23 AM, Robbie Gemmell wrote:
>
>> 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.
>>
>
> Yes, and I don't want to overcomplicate things. In some cases 'product'
> might be a little ambiguous is all.
>
>
> 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).
>>
>
> Agreed.
>
>
> 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.
>>
>
> Related to that, would a separate version be needed, or could that be
> included in the product? The main case I can think of where you might want
> programmatic access to this is in choosing (hopefully temporary!)
> workarounds for different interop issues.
>
>
>
The main reason I was looking to pick 'product' and 'version' was for the
historical consistency (theyve been defined that way since at least 0-8),
and then partly just based on how we currently use them in the Java broker
by sending them to the client, and explicitly logging the clients
product+version along with some other things for new connections. I have no
real issue with combining their values.
Re: AMQP 1.0 connection property names
Posted by Robbie Gemmell <ro...@gmail.com>.
On 14 May 2014 17:54, Gordon Sim <gs...@redhat.com> wrote:
> On 05/14/2014 10:23 AM, Robbie Gemmell wrote:
>
>> 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.
>>
>
> Yes, and I don't want to overcomplicate things. In some cases 'product'
> might be a little ambiguous is all.
>
>
> 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).
>>
>
> Agreed.
>
>
> 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.
>>
>
> Related to that, would a separate version be needed, or could that be
> included in the product? The main case I can think of where you might want
> programmatic access to this is in choosing (hopefully temporary!)
> workarounds for different interop issues.
>
>
>
The main reason I was looking to pick 'product' and 'version' was for the
historical consistency (theyve been defined that way since at least 0-8),
and then partly just based on how we currently use them in the Java broker
by sending them to the client, and explicitly logging the clients
product+version along with some other things for new connections. I have no
real issue with combining their values.
Re: AMQP 1.0 connection property names
Posted by Gordon Sim <gs...@redhat.com>.
On 05/14/2014 10:23 AM, Robbie Gemmell wrote:
> 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.
Yes, and I don't want to overcomplicate things. In some cases 'product'
might be a little ambiguous is all.
> 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).
Agreed.
> 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.
Related to that, would a separate version be needed, or could that be
included in the product? The main case I can think of where you might
want programmatic access to this is in choosing (hopefully temporary!)
workarounds for different interop issues.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: AMQP 1.0 connection property names
Posted by Gordon Sim <gs...@redhat.com>.
On 05/14/2014 10:23 AM, Robbie Gemmell wrote:
> 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.
Yes, and I don't want to overcomplicate things. In some cases 'product'
might be a little ambiguous is all.
> 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).
Agreed.
> 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.
Related to that, would a separate version be needed, or could that be
included in the product? The main case I can think of where you might
want programmatic access to this is in choosing (hopefully temporary!)
workarounds for different interop issues.
Re: AMQP 1.0 connection property names
Posted by Rob Godfrey <ro...@gmail.com>.
On 14 May 2014 02:23, Robbie Gemmell <ro...@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 <gs...@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
>
Re: AMQP 1.0 connection property names
Posted by Robbie Gemmell <ro...@gmail.com>.
Now that Gordons email has arrived for me, I'll reply to the rest of it :)
On 13 May 2014 17:31, Gordon Sim <gs...@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)
Robbie
Re: AMQP 1.0 connection property names
Posted by Justin Ross <jr...@apache.org>.
On Tue, May 13, 2014 at 12:31 PM, Gordon Sim <gs...@redhat.com> wrote:
>
> 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?
I like those. I don't think brevity is important in this case, and those
names are very clear to me.
Out of curiosity, is there any interest in offering the command line (a la
"process_command_line")? The arguments passed to a process can often be
used to distinguish it from others quickly.
Re: AMQP 1.0 connection property names
Posted by Robbie Gemmell <ro...@gmail.com>.
Now that Gordons email has arrived for me, I'll reply to the rest of it :)
On 13 May 2014 17:31, Gordon Sim <gs...@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)
Robbie
Re: AMQP 1.0 connection property names
Posted by Gordon Sim <gs...@redhat.com>.
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 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?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: AMQP 1.0 connection property names
Posted by Chuck Rolke <cr...@redhat.com>.
I like having registered properties especially for common cases.
'client-pid' and 'client-name' would be my first vote.
'pid' and 'pname' second.
'pid' and 'process' third.
-C
----- Original Message -----
> From: "Robbie Gemmell" <ro...@gmail.com>
> To: users@qpid.apache.org
> Cc: dev@activemq.apache.org
> Sent: Tuesday, May 13, 2014 11:47:30 AM
> Subject: Re: AMQP 1.0 connection property names
>
> 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 <gs...@redhat.com> 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: users-unsubscribe@qpid.apache.org
> > For additional commands, e-mail: users-help@qpid.apache.org
> >
> >
>
Re: AMQP 1.0 connection property names
Posted by Gordon Sim <gs...@redhat.com>.
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 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?
Re: AMQP 1.0 connection property names
Posted by Robbie Gemmell <ro...@gmail.com>.
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 <gs...@redhat.com> 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: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
Re: AMQP 1.0 connection property names
Posted by Robbie Gemmell <ro...@gmail.com>.
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 <gs...@redhat.com> 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: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>