<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 25, 2016 at 2:03 PM, Galder Zamarreño <span dir="ltr"><<a href="mailto:galder@redhat.com" target="_blank">galder@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi all,<br>
<br>
As I write the Javascript client for Hot Rod, and Vittorio writes the C++ client, the question the encoding of the byte arrays has popped up.<br>
<br>
The reason why encoding matters is mainly because of compatibility mode. How does a Hot Rod client know how it should transform something a REST client set?<br>
<br>
To be able to answer this question correctly, the Hot Rod client needs to know the type of the data.<br>
<br>
Although we could consider adding encoding information to the Hot Rod protocol long term, in the short term this question might already been answered by Protostream.<br></blockquote><div><br><br>Compatibility between disparate clients should certainly be supported, but what about a pluggable marshaller mechanism? Let's consider all usage scenarios:<br></div><div><br></div><div>* Only Java clients: in most cases, JBoss marshalling is adequate, no need to involve protobuf or json and since JBoss Marshalling is default, no need to configure anything.<br><br></div><div>* Mix of Java and C++/C#/Python clients: the Protobuf encoding works wonderfully for that. The client could be configured to use the protostream marshaller, the same for the server.<br></div><div><br>* Mix of Java, C++/C#/Python and REST clients: protobuf with json [1] encoding is an interesting option. Same as above, a protostream marshaller with json support could <br>be configured both on client and server.<br></div><div><br>* Custom marshallers: consider FlatBuffers [2], for example, an interesting new cross-platform serializer that allows to access serialized data without de-serializing the whole payload, <br></div><div>and without generating any transient memory, and it optionally supports JSON. It could be interesting to write a marshaller based on it and plug it on Infinispan.<br></div><div><br></div><div>Although we have a way of configuring the marshaller on client (via RemoteCacheManager) and server (deployable jar), there'd be more work to do in order make them really pluggable:<br><br>- Some serialization formats like Protobuf and [2] require interface description to be available on both client and server. This is not supported for all marshallers, just for Protostream<br>- Remote query requires some metadata regarding which fields to index and how, and this would need to be possible on every language regardless of the marshalling.<br>Currently, this info can be encoded in the .proto file only, a custom marshaller would not work.<br>- Currently remote query is settled on protobuf not only for the byte array but for the the HotRod query request and response [3]<br><br></div><div>Is having a pluggable serializer mechanism too far fetched, given the effort already invested towards protobuf? <br></div><div><br></div><div>Gustavo<br></div><div><br>[1] <a href="https://developers.google.com/protocol-buffers/docs/proto3#json" target="_blank">https://developers.google.com/protocol-buffers/docs/proto3#json</a><br>[2] <a href="https://google.github.io/flatbuffers/" target="_blank">https://google.github.io/flatbuffers/</a><br>[2] <a href="https://code.facebook.com/posts/872547912839369/improving-facebook-s-performance-on-android-with-flatbuffers/" target="_blank">https://code.facebook.com/posts/872547912839369/improving-facebook-s-performance-on-android-with-flatbuffers/</a><br>[3] <a href="https://github.com/infinispan/infinispan/blob/master/remote-query/remote-query-client/src/main/resources/org/infinispan/query/remote/client/query.proto" target="_blank">https://github.com/infinispan/infinispan/blob/master/remote-query/remote-query-client/src/main/resources/org/infinispan/query/remote/client/query.proto</a> <br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<br>
_______________________________________________<br>
infinispan-dev mailing list<br>
<a href="mailto:infinispan-dev@lists.jboss.org" target="_blank">infinispan-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a></blockquote></div><br></div></div>