On 14 May 2014 17:54, Gordon Sim <[email protected]> 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.
