On Nov 19, 2013, at 12:23 PM, Radim Vansa <rva...@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 gal...@redhat.com twitter.com/galderz Project Lead, Escalante http://escalante.io Engineer, Infinispan http://infinispan.org _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
