Re: [infinispan-dev] Hot Rod encoding

On Wed, Feb 3, 2016 at 1:07 PM, Adrian Nistor wrote: > > 2. better support for remote query for java clients using > jbossmarshalling (in compat mode only). > Would require hibernate-search > annotated entities be available on server too, but would spare the user > from

Re: [infinispan-dev] Hot Rod encoding

Note that in a future version of hibernate search - soon I hope, the encoding will no longer be a problem. You will be able to provide a navigation/traversal API that will know how to read things from your blob. It's called free form entity by its friends. > On 17 févr. 2016, at 12:35, Galder

Re: [infinispan-dev] Hot Rod encoding

> On 3 Feb 2016, at 14:07, Adrian Nistor wrote: > > Hi all, > > > > Re Protostream, it is just plain Protobuf folks! It's in no way a > customly-modified-encoding-loosely-based-on-protobuf. The only apparent > twist is our usage of Protobuf, which btw also follows

Re: [infinispan-dev] Hot Rod encoding

I like the idea of pluggable serialization/marshalling, but as you rightly explained, what flexibility gives you you lose by lack of functionality. E.g. querying is only available for protostream based encoding. So, I think we need to remove the hard bind between functionality and encoding to

Re: [infinispan-dev] Hot Rod encoding

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".

Re: [infinispan-dev] Hot Rod encoding

On Mon, Jan 25, 2016 at 2:03 PM, Galder Zamarreño wrote: > 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

Re: [infinispan-dev] Hot Rod encoding

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".

Re: [infinispan-dev] Hot Rod encoding

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

Re: [infinispan-dev] Hot Rod encoding

Hi all, Experimenting with custom marshallers is possible right now. People just loose query support doing so. Freedom has its cost ... (kidding) There are a few simple things we can do right now to better support at least two client categories (and not loose query support) without much

[infinispan-dev] Hot Rod encoding

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