This is a great suggestion. I was thinking a bit about it and wondered if it would be more flexible to include the entire "client properties" map in the events rather than just the three properties mentioned above.
What do you think? Right now, the QPID clients put the pid, ppid, and command name into the "client-properties" map. In theory, a non-QPID 0.10 client can put anything they'd like into it - so there's really no guarantee that pid, ppid, and command name have to be there. (see the description of the connection.start-ok command in the 0.10 spec).
In AMQP 1.0, the Connection Open frame has an equivalent field for connection properties, which, I assume, would serve the same role for 1.0-based clients (see the description of the Open frame in the Performative section of the AMQP-1.0 spec)
So, the argument list of the QMF events above would instead be something like this:
<arg name="clientProperties" type="map" desc="A map containing optional information about the remote client"/>
<event name="clientConnect" sev="inform" args="rhost, user, clientProperties"/>
<event name="clientConnectFail" sev="warn" args="rhost, user, reason, clientProperties"/>
<event name="clientDisconnect" sev="inform" args="rhost, user, clientProperties"/>
And the pid, ppid, and command name could be accessed via the clientProperties map using the keys "qpid.client_pid", "qpid.client_ppid", and "qpid.client_process", respectively.
The benefit of this approach is that it allows us to add new properties in the future without having to write additional QMF code to support them. The downside is that the management app would have to index the map manually.
Just a consideration - what do you think?