@matt Very much so, case in point would be the Avro use case. It plays very nicely to interop object/data serialisation with c++ clients. Or like wise some of the other serialisation options out there.
This is why I suggest a not Java specific but more generic/widely adopted content-type media type header. Sent from my iPhone > On 31 May 2017, at 20:02, Clebert Suconic <[email protected]> wrote: > > 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
