On 09/04/2013 06:06 PM, Andrew Stitcher wrote:
I think the fundamental question here is what is the API model of message properties: Until now the API has been loosely modeled (for better or worse) on JMS - JMS has no distinction as to different kinds of message properties (as far as I know). Adding in different kinds of message properties may possibly make this API too focussed on amqp 1.0 if we ever want to attach different protocols to it. However if we've taken a decision that it's only meant to represent amqp 1.0 then I think this is fine.
I don't think its only meant to represent AMQP 1.0, but I do think it should be possible to express the distinction should be in some way when using a protocol where the distinction is relevant (e.g. AMQP 1.0).
So as it stands, the connection-option is only available on AMQP 1.0, and if the distinction is important to an application they turn it on and the annotations are exposed as a sub-map.
With the approach of adding extra accessors, over a protocol that didn't support annotations as distinct from application properties, the properties map and application properties map would always be identical and the annotations map would always be empty.
I was under the impression that one of the original design goals of the qpid messaging API was not to be overly protocol specific in the API and to add protocol specific nuances via configuration options/text strings. Given that, I like the idea that normal applications, when reading properties at least, don't have to known what kind of property is being read.
Agreed, and in both the current code and the suggested extended API, that would remain the case.
However if setting properties on a message this may need to be more explicit. Also perhaps there should be a "property property" which can tell you the kind of property you read.
--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
