[infinispan-dev] Hot Rod encoding

[Gustavo Fernandes]

On Wed, Feb 3, 2016 at 11:27 AM, Sanne Grinovero <sanne at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20160203/4202ff91/attachment.html