On 03 Apr 2014, at 10:05, Dan Berindei <dan.berindei(a)gmail.com> wrote:
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.
Possibly, I did consider passing some data from the client to the filter/converter factory
objects, but could not think of a very clean solution. One option would be for the
protocol to specify a vInt, indicating the number of parameters, and then each parameter
as byte[] with its length prepended. A java hot rod client could marshall the parameters
into byte[]. For the server side implementations, they could receive an Object[] as
parameter in the callback with the unmarshalled versions.
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
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
galder(a)redhat.com
twitter.com/galderz