Nice work! Few questions: - in the context of near-caching, entry-modified and entry-deleted would have the same effect on the client: invalidation of data. If near-caching is our main goal, we might as well send a single notification type (entry-modified) for both modification and deletion (the deletion is just a particular case of modification). Just an idea. - how does the server know that a request originated from a certain client in order not to send it to that client again? There's no clientId in the request...
On Nov 12, 2013, at 3:17 PM, Galder Zamarreño <gal...@redhat.com> wrote: > Hi all, > > Re: https://github.com/infinispan/infinispan/wiki/Remote-Hot-Rod-Events > > I've just finished writing up the Hot Rod remote events design document. > Amongst many other use cases, this will enable near caching use cases with > the help of Hot Rod client callbacks. > > 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 Cheers, -- Mircea Markus Infinispan lead (www.infinispan.org) _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
