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