Oipo commented on issue #185: Add custom serialization service for custom delete functions in RSA URL: https://github.com/apache/celix/pull/185#issuecomment-610817825 > > +1 to supporting fqn+version. However, I can still think of a use case for also supporting targeting service ids. Suppose a user has a remoted service X with serialization json and twenty java applications that communicate with X. User wants to move to serialization msgpack. Not wanting to upgrade all services communicating with service X at once, the user simply spins up two instances with a different filter (e.g. (service.serialization=json) and (service.serialization=msgpack)) so that upgrading can ben done per java application, instead of having to do twenty at the same time. > > If a list of message types or something is used in the service properties, both could support the same types, but with service ranking preference to one of the other could be given. > So in your example: > JSON has a service property: message.types={ "a", "b", "c"} with a ranking of 10 > MSGPack has a service property: message.types={"a", "c"} with a ranking of 20 > In this case the RSA would still pick up both serializers, and starts at the highest ranking to find a handler for a message, moving down the list. > So for msg "a" it would use MSGPack, while for msg "b" it would use JSON. Oh, perfect! Then nevermind my comment :) IMO, this PR can be (ab)used for implementing the suggestion of Pepijn; people will most likely wait to use the service until after the serde functions have been implemented, as that would prevent double work. Only downside is if it fits in the scope of our sprint or not :)
---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected] With regards, Apache Git Services
