<div dir="ltr">On Wed, Feb 3, 2016 at 1:07 PM, Adrian Nistor <span dir="ltr"><<a href="mailto:anistor@redhat.com" target="_blank">anistor@redhat.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
2. better support for remote query for java clients using<br>
jbossmarshalling (in compat mode only). <br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Would require hibernate-search<br>
annotated entities be available on server too, but would spare the user<br>
from touching protobuf if he's not interested in interop. The only<br>
reason this does not work already is because it was not among the<br>
initial set of requirements when designing remote query. 2.5 years later<br>
it is clearly a must.<br></blockquote><div><br><br></div><div>Further down the line, we'd probably benefit from having a language neutral way of describing index <br>configuration (analyzers,fields, classes etc). This config would not be tied to hibernate search or any particular <br>marshaller and it could be automatically inferred for java users if they already have hibernate search annotated <br></div><div>classes. Having this would allow fulltext capabilities from any language and across marhsallers. WDYT?<br><br><br></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Infinispan 9 is not too far, so I propose to implement 1 and 2 as a<br>
first step, then see what is the right time frame for the more involved<br>
step of decoupling query module's source of metadata form the protobuf<br>
schema/marshaller. I think this refactoring deserves to be done even for<br>
the sake of elegance and maintainability, if not for plugability.<br></blockquote><div><br>+1<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>
Re Protostream, it is just plain Protobuf folks! It's in no way a<br>
customly-modified-encoding-loosely-based-on-protobuf. </blockquote><div><br></div><div>That's clear :) , but looking at the Hot Rod protocol documentation, the Query request itself <br></div><div>is encoded in protobuf [1], not only the struct with key/values. Wouldn't it be better to isolate<br></div><div>what is marshaller byproduct and what is Hot Rod protocol related? This will<br></div><div>make the job of the Hot Rod client implementors easier, and it'd be another step towards a pluggable<br></div><div>marshaller.<br></div><div><br>[1] <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><div>Gustavo<br></div></div></div></div>