[infinispan-dev] data interoperability and remote querying

Mircea Markus mmarkus at redhat.com
Wed Apr 10 13:30:48 EDT 2013


On 10 Apr 2013, at 18:18, Emmanuel Bernard wrote:

> I favor the first options for a few reasons:
> 
> - much easier client side implementations
>  Frankly rewriting the analyzer logic of Lucene in every languages is
>  not a piece of cake and you are out of luck for custom analyzers
> - more robust client implementation: if we change how indexing is done
>  clients don't have to change
> - reindexing: if there is a need to rebuild the index, or if the user
>  decides to reindex data differently, you must be able to read the data
>  on the server side
> - validation: if you want to implement (cross entry) validation, the
>  server needs to be able to read the data.
> - async, validation and indexing can be done in an async way on the
>  server and avoid perceived latency from a client requiest to the
>  result
> 
> I'm not sure JSON should be the format though. As you said it's quite
> verbose and string is not exactly the most efficient way to process
> data.
+1 to all the points above.

Cheers,
-- 
Mircea Markus
Infinispan lead (www.infinispan.org)






More information about the infinispan-dev mailing list