On Thu, Feb 19, 2015 at 5:41 AM, Robbie Gemmell <robbie.gemm...@gmail.com> wrote:
> On 19 February 2015 at 04:22, Rafael Schloming <r...@alum.mit.edu> wrote: > > On Wed, Feb 18, 2015 at 3:58 PM, Rajith Muditha Attapattu < > > rajit...@gmail.com> wrote: > > > >> Setting the message body for an o.a.q.proton.message.Message is slightly > >> awkward. > >> You have to create a AmqpValue. AmqpSequence or a Data object that > >> encapsulates the underlying data type. > >> > >> Given that one of our goals is to expose an API that works with standard > >> Java types instead of AMQP defined types, I suggest we simply use Object > >> for setBody and getBody methods. > >> The implementation can then handle the conversion back and forth > >> underneath. > >> > >> What do you think? > >> > > > > Makes sense to me. > > > > --Rafael > > Adding additional functionality to set/get a 'body object' like this > certainly might be useful in cases, but I dont think it should be the > only way. I also wouldnt change the existing methods to do this unless > the idea is to let you continue setting/getting the existing Section > objects unchanged (it would obviously likely break all existing user > code sending payloads otherwise). I can see that being easy enough for > the setter as it works now, though I dont see how it could work for > the getter without adding a control toggle. > The Message interface is part of the public API and I understand the impact on existing code out there. **I don't plan to remove anything or even change any existing public API. At least not for the upcoming release.** So far I have sketched out a parallel API for certain pieces of the public API. Message handling is one of them. What I would like to have is a discussion based on that, as it appears the existing API had little discussion or scrutiny. An API should be easy to use and work with standard Java types as much as possible. The existing API is awkward to use in that respect. If I want to send a String or a Map, I have to wrap it with an AMQP type first. Which is awkward at best. > Doing this would simply some use cases, but also further restrict the > ability to send the bodies you want or know what you really received, > e.g is a List an AmqpvValue+List or an AmqpSequence? >From a typical application programmers perspective, a List wrapped in an AmqpValue or an AmqpSequence makes little difference. What the user cares about is that it's a List, not the underlying AMQP type. Unless I have missed some subtlety, I don't see much of a benefit in figuring out what the underlying AMQP type is. If they care about that level of detail, then perhaps they are working at the wrong level of granularity. They should instead use the codec API for that. Robbie, can you please give us a use case to further explain your point? > Is <some-object> > an AmqpValue+Binary, or is it a Data? Again the same question. For 99% of the use cases out there, the user will only care about the underlying byte[]. Could you pls let us know a use case where such a distinction is useful ? > There is then things like how to > support e.g multiple Data and AmqpSequence sections (something it > should already support but doesnt). > > Yea I noticed this was missing. More thoughts on that later. > Robbie >
