Don't we want to allow the user to pass some data to the filter factory
on registration?
Otherwise we'd force the user to write a separate filter factory class
every time they want to track changes to a single key.
Cheers
Dan
On Wed, Apr 2, 2014 at 2:14 PM, Galder Zamarreño <galder(a)redhat.com>
wrote:
Hi all,
I’ve finally managed to get around to updating the remote hot rod
event design wiki [1].
The biggest changes are related to piggybacking on the cluster
listeners functionality in order to for registration/deregistration
of listeners and handling failure scenarios. This should simplify the
actual implementation on the Hot Rod side.
Based on feedback, I’ve also changed some of the class names so
that it’s clearer what’s client side and what’s server side.
A very important change is the fact that source id information has
gone. This is primarily because near-cache like implementations
cannot make assumptions on what to store in the near caches when the
client invokes operations. Such implementations need to act purely on
the events received.
Finally, a filter/converter plugging mechanism will be done via
factory implementations, which provide more flexibility on the way
filter/converter instances are created. This opens the possibility
for filter/converter factory parameters to be added to the protocol
and passed, after unmarshalling, to the factory callbacks (this is
not included right now).
I hope to get started on this in the next few days, so feedback at
this point is crucial to get a solid first release.
Cheers,
[1]
https://github.com/infinispan/infinispan/wiki/Remote-Hot-Rod-Events
--
Galder Zamarreño
galder(a)redhat.com
twitter.com/galderz
Project Lead, Escalante
http://escalante.io
Engineer, Infinispan
http://infinispan.org
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev