On Wed, Feb 3, 2016 at 11:27 AM, Sanne Grinovero <sanne@infinispan.org> 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