Re: [infinispan-dev] Hot Rod encoding
On Wed, Feb 3, 2016 at 1:07 PM, Adrian Nistor <anistor(a)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-...
Gustavo
Attachments:
- attachment.html (text/html — 3.1 KB)