[infinispan-dev] Design of Remote Hot Rod events

[Galder Zamarreño]

On Nov 19, 2013, at 12:23 PM, Radim Vansa <rvansa at redhat.com> wrote:

> On 11/19/2013 09:48 AM, Emmanuel Bernard wrote:
>> </snip>
> 
>> 
>> In that use case the listener code runs a filtering logic server side
>> and only send keys that are impacted by the query plus some flag
>> defining whether it's added to changed or removed from the corpus.
>> The key is filtering event before sending it to the client.
>> 
>> I wish the design document was showing how we can achieve a general
>> purpose remote listener approach but have a step 1 that is only
>> targeting a restricted set of listeners if you feel that it's too much
>> to chew. I don't want us to be trapped in a situation where backward
>> compatibility prevent us from adding use cases.
> I was also suggesting that listener on particular key should be 
> mandatory requirement. However, any general server-side filtering logic 
> would be hard to specify as HotRod is language-unaware binary protocol. 
> Therefore, the best you could get is some kind of binary regular 
> expressions. For the start, global/one-key filtering is a good start and 
> the door are not closed for any further options.

Ideally, all filtering should probably be done server, both for type of operation and per-key filtering. If as you rightly say, some client cannot apply filtering per-key cleanly on the server side, they can always apply filtering client-side based on a client specific implementation, but that should be last resort.

Per-cache operation filtering should really be done server side.

Cheers,
--
Galder Zamarreño
galder at redhat.com
twitter.com/galderz

Project Lead, Escalante
http://escalante.io

Engineer, Infinispan
http://infinispan.org