Hi all, 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.
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? To be able to answer this question correctly, the Hot Rod client needs to know the type of the data. 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. Protostream based marshaller adds encoding to the byte arrays by adding information of what the type of that is written, whether raw type or complex. Protostream is based around Protobuf which works well as medium for compatibility mode. So, in essence, if we want get different clients working together, the simplest thing to do is to implement the Protostream marshaller in each client lang, and they should work together without probs. This option has the downside that by limiting our compatibility marshalling to Protostream, how would a standard REST client would understand this format? They'd need to have a way to understand Protostream... Another option would be to setlle on UTF-8 String as compatibility medium and get the languages to convert types into JSON UTF-8 String. I think this would work better for REST-based clients. Also, AFAIK protobuf objects can be transformed into JSON, so if there's already a protostream marshaller available, that can be used to transform to JSON. Down the line we might want to add encoding to Hot Rod or switch to a technology where encoding is sorted out for us, e.g. HTTP-based protocols... Thoughts? Cheers, -- Galder Zamarreño Infinispan, Red Hat _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
