[infinispan-dev] Hot Rod encoding

[Gustavo Fernandes]

On Wed, Feb 3, 2016 at 1:07 PM, Adrian Nistor <anistor at redhat.com> 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 touching protobuf if he's not interested in interop. The only
> reason this does not work already is because it was not among the
> initial set of requirements when designing remote query. 2.5 years later
> it is clearly a must.
>


Further down the line, we'd probably benefit from having a language neutral
way of describing index
configuration (analyzers,fields, classes etc). This config would not be
tied to hibernate search or any particular
marshaller and it could be automatically inferred for java users if they
already have hibernate search annotated
classes. Having this would allow fulltext capabilities from any language
and across marhsallers. WDYT?



> Infinispan 9 is not too far, so I propose to implement 1 and 2 as a
> first step, then see what is the right time frame for the more involved
> step of decoupling query module's source of metadata form the protobuf
> schema/marshaller. I think this refactoring deserves to be done even for
> the sake of elegance and maintainability, if not for plugability.
>

+1


>
> Re Protostream, it is just plain Protobuf folks! It's in no way a
> customly-modified-encoding-loosely-based-on-protobuf.


That's clear :) , but looking at the Hot Rod protocol documentation, the
Query request itself
is encoded in protobuf [1], not only the struct with key/values. Wouldn't
it be better to isolate
what is marshaller byproduct and what is Hot Rod protocol related? This will
make the job of the Hot Rod client implementors easier, and it'd be another
step towards a pluggable
marshaller.

[1]
https://github.com/infinispan/infinispan/blob/master/remote-query/remote-query-client/src/main/resources/org/infinispan/query/remote/client/query.proto

Gustavo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20160224/ca701834/attachment.html