I'm a bit confused about what API are you talking about... do you intend for having that as an extension of the JMS Client.. (including qpid).. or as a tooling in which you could convert bytes and buffers to the intended format.
On Wed, May 31, 2017 at 2:44 PM, Michael André Pearce <[email protected]> wrote: > Hi Matt, > > I would suggest that serdes have to provide a mime type, we will have to add > method to expose this, and then we set content-type to the provided mime type > string. > > Maybe simple method: > > String mimeType() > > As such if on byte message on consume if custom serdes exist and content type > header exists and matches that returned from the serdes we deserialise via > custom. > > > > > Sent from my iPhone > >> On 31 May 2017, at 17:58, Matt Pavlovich <[email protected]> wrote: >> >> Hey Mike- >> >> You bring up some good points about keeping the serialization simple and >> separate. I’m good w/ that approach. >> >> The API you propose doesn’t seem to indicate a place to touch the message >> headers. Are you suggesting that the Artemis client-side SerDes handler >> would have a convention where it would set the classname or other in a >> standard header? BTW— I think that defining a standard convention would be >> preferred. users could still have access to headers / properties ahead of >> calling the .send(..). >> >> -Thanks, >> Matt >> >>> On May 30, 2017, at 9:00 PM, Michael André Pearce >>> <[email protected]> wrote: >>> >>> Hi Matt, >>> >>> I think having just a SerDe interface for payload handling separate from a >>> general interceptor / client side plugin, is beneficial as then it keeps >>> the logic for serialsation well encapsulated. And also cleaner if we need >>> to do anything (eg sending it as a bytesmessags with a header flag) >>> >>> I see this very much like difference in kafka where you have payload >>> serialisation (serdes) and custom-plugin (interceptors) >>> >>> Also having just a serde makes interface for people to implement and care >>> about much simpler. Eg this is almost the interface I would expect: >>> >>> byte[] serialize(Destination destination, Object o) >>> >>> Object deserialize(Destination destination, byte[] bytes) >>> >>> Nice and simple to implement without having to care about anything else. >>> >>> Cheers >>> Mike >>> >>> >>> Sent from my iPhone >>> >>>> On 30 May 2017, at 23:18, Matt Pavlovich <[email protected]> wrote: >>>> >>>> Michael- >>>> >>>> +1 dealing with bytes messages is preferred to object messages and custom >>>> object SerDes is super useful. >>>> >>>> What do you think about considering a generic client-side plugin approach >>>> vs just a payload handler? >>>> >>>>> On May 30, 2017, at 4:03 PM, Michael André Pearce >>>>> <[email protected]> wrote: >>>>> >>>>> If present then this would be used to serialise the Object instead of the >>>>> default, and subsequently create/convert to a BytesMessage, with a header >>>>> set to denote it was custom serialised. >>>> >> -- Clebert Suconic
