@Clebert As a extension to the JMS Client.
Just to set the real use case We want to send Avro records, we know that with a schema registry the serialised bytes are of orders of magnitude less and also faster at serialising than letting the java serialisation do it. As well it allows for version projection of the data. Though obviously we know/aware that others may want to use other serialisation of their objects. Intent is just to plug / configure the serialisation/deserialisation impl in the connection factory. So on ObjectMessage send if present instead of Java serialisation that occurs currently it uses the custom serdes. Very similar to kafka producer/consumer. 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
