On Wed, Feb 3, 2016 at 11:27 AM, Sanne Grinovero <[email protected]> wrote:
> It sounds like a good idea, almost like a natural evolution, but to > play devil's advocate I'll try to find some drawbacks for such a > decision. > > One negative argument is overall complexity: there are many points in > code in which one needs to consider that the encoding might be > "something else". This isn't a new problem as we already support two > modes, but we've soon how much more difficult it makes things and this > is making things even a bit more complex. > Ideally those several points would need to be formalized into an SPI, allowing customizations like it was done for Avro [1] a bit easier maybe. I am not familiar with all those points, but I imagine it'd be a complex refactor nonetheless :) > The other problem I see is that this severely complicates > interoperability between different clients. Suppose two applications > are being developed to use the Infinispan Server and decide to use two > different encoders, I suspect that at some point they'll regret it > when needing one to access some data from the other... not suggesting > that this should be a good practice, but still it would be very > inconvenient. > > I think the issue is the same that happens today: a remote java client using JBoss marshaller wants to start doing queries, it will not work because the server expects Protobuf. > Finally, tooling. We'll eventually need to work on better tooling and > supporting multiple encoders would spread efforts thinly. > I assume you mean tooling to build interface definitions in the case of protobuf or similar? They might already be out there [2][3][4] Gustavo [1] https://github.com/leads-project/infinispan-avro [2] https://code.google.com/p/protobuf-dt/ [3] https://plugins.jetbrains.com/plugin/4942?pr=idea [4] https://plugins.jetbrains.com/plugin/7971?pr=idea
_______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
