On 04/11/2014 02:03 PM, Galder Zamarreño wrote: > 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.
From the protocol perspective, byte array is IMO the most simplest = most elegant. Server implementations must be able to process any byte array as well (in order to support non-Java clients) - therefore, there has to be interface accepting raw byte[]. For convenience, we could provide abstract wrapper implementing the interface, marshalling it into Object[] and passing to abstract method. Radim > >> 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 -- Radim Vansa <[email protected]> JBoss DataGrid QA _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
