On Wed, 2013-09-04 at 16:03 +0100, Gordon Sim wrote: > On 09/04/2013 03:34 PM, Gordon Sim wrote: > > On 09/04/2013 03:14 PM, Alan Conway wrote: > >> Having a connection option that changes how messages are presented seems > >> confusing and error prone. > > > > I'm not sure I agree. I don't really see a problem with the behaviour > > being configurable. And if it is, doing so at the granularity of > > connection seems reasonable to me. > > An alternative to being configurable would be to add a distinct way of > accessing annotations, accessing application properties and accessing > the combined set. > > E.g. we could add getAnnotations() and getApplicationProperties() > alongside the existing getProperties() (the existing method would be the > combination of annotations and application properties). > > That way in switching from 0-10 (which doesn't make a distinction) to > 1.0 (which does), the getProperties() works the same, but if needed > there are ways to treat them as distinct. > > What do you think? I think I prefer that.
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 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. 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. Andrew --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
