[infinispan-dev] Remote Hot Rod events wiki updated

[Radim Vansa]

On 04/11/2014 02:03 PM, Galder Zamarreño wrote:
> On 03 Apr 2014, at 10:05, Dan Berindei <dan.berindei at 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.

 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 <galder at 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 at redhat.com
>>> twitter.com/galderz
>>>
>>> Project Lead, Escalante
>>>
>>> http://escalante.io
>>>
>>>
>>> Engineer, Infinispan
>>>
>>> http://infinispan.org
>>>
>>>
>>>
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev at lists.jboss.org
>>>
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> --
> Galder Zamarreño
> galder at redhat.com
> twitter.com/galderz
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


-- 
Radim Vansa <rvansa at redhat.com>
JBoss DataGrid QA