On 03 Apr 2014, at 10:05, Dan Berindei <[email protected]> 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 <[email protected]> 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 >> [email protected] >> twitter.com/galderz >> >> Project Lead, Escalante >> >> http://escalante.io >> >> >> Engineer, Infinispan >> >> http://infinispan.org >> >> >> >> _______________________________________________ >> infinispan-dev mailing list >> [email protected] >> >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > _______________________________________________ > infinispan-dev mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Galder Zamarreño [email protected] twitter.com/galderz _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
