On Tue, Sep 23, 2014 at 9:57 AM, Mircea Markus <mmar...@redhat.com> wrote: > > On Sep 23, 2014, at 16:39, William Burns <mudokon...@gmail.com> wrote: > >> On Tue, Sep 23, 2014 at 9:31 AM, Mircea Markus <mmar...@redhat.com> wrote: >>> >>> On Sep 23, 2014, at 16:27, Emmanuel Bernard <emman...@hibernate.org> wrote: >>> >>>> >>>> On 23 Sep 2014, at 14:53, Mircea Markus <mmar...@redhat.com> wrote: >>>> >>>>> On Sep 23, 2014, at 15:18, Emmanuel Bernard <emman...@hibernate.org> >>>>> wrote: >>>>> >>>>>>> I am not sold on this as it seems pretty trivial to decipher which >>>>>>> operation is which and the information would be present on the >>>>>>> javadocs as well. >>>>>> >>>>>> I very strongly disagree. Cf the other thread with Radim 's comment on >>>>>> topology error. >>>>>> And think about *future* evolutions. The enum would make that much >>>>>> safer. In the bin enum world you would have to introduce a new >>>>>> YetAnotherKeyValueFilter interface :) >>>>> >>>>> Nicer than an enum would be an explicit method, e.g. >>>>> handlePut/handleDelete/handleCreate/handleUpdate, as these would also >>>>> receive the appropriate param list. Of course this means moving away from >>>>> the KeyValueFilter to an UpdateFilter (good name, Radim) used only for >>>>> cluster listeners. >> >> I like the name as well :) The only thing that I dislike about the >> extra methods is the fact that it isn't a Functional interface, which >> would be nice to have when we ever move to Java 8, but that may be >> thinking too f?ar into the future :P > > Agreed, OTOH having a functional interface implemented with a switch > statement around the op type wouldn't be too nice either. > >> >>>>> Will, what would be the overall impact on the A >> >> The biggest part is the usage with the cluster iterator. Currently >> the Listener uses the same filter that it is provided to also do the >> iteration. If we want to go down the line of having the extra >> interface(s), which overall I do like, then I am thinking we may want >> to change the Listener annotation to no longer have an >> includeCurrentState parameter and instead add a new method to the >> addListener method of Cache that takes a KeyValueFilter and the new >> UpdateFilter (as well as the 2 converters). > > Do we still want to keep the KeyValueFilter method or replace it entirely > with the UpdateFilter version?
In this case I would assume this new UpdateFilter would be completely separate (doesn't extend) and would not contain the KeyValueFilter method. Also I would think UpdateFilter would live only in the notifications package as it doesn't make much sense outside of this context (the others would stay in filter package). > >> I can then add in 2 >> bridge implementations so that you don't have to implement the other >> if your implementation can handle both types. Also from the other >> post it seems that I should add the retry boolean to all the >> appropriate methods so that you can have a chance to detect if an >> update was missed. Unless this seems to cumbersome? > > Cheers, > -- > Mircea Markus > Infinispan lead (www.infinispan.org) > > > > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
