On Nov 19, 2013, at 12:23 PM, Radim Vansa <rvansa(a)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(a)redhat.com
twitter.com/galderz
Project Lead, Escalante
http://escalante.io
Engineer, Infinispan
http://infinispan.org