Much better. Some more feedback. == Filter and converter
I am wondering if there is a benefit in separating filters and converters. It does add some understanding complexity so a single ServerListener with the methods from RemoteFilter / RemoveConverter might be better. Should filter / converter impls have a @FilterId() / @ConverterId or should even the id be configured as late binding? == Custom event contents I an not following, is the custom content always received as byte[] by the client? Or is the generic parameter K in RemoteCacheEntryCustomEvent<K> the actual return type of getEventData() ? I'd love (in Java) to declare the returned type of the converter via generics in the RemoteConverter impl (class SomeRC<String> extends RemoteConverter<String> {}) and somehow use that information on the client side. == Example of continuous query atop remote listeners Thinking about how to implement continuous query atop this infrastructure I am missing a few things. The primary problem is that I don't want to enlist a filter id per continuous query I want to run. Not only that but I'd love to be able to add a continuous query on the fly and disable it on the fly as well per client. For that filters and converters are not flexible enough. What is missing is the ability to pass parameters from the client to the remote filter and remote converter. Parameters should be provided *per client*. Say Client 1 register the continuous query listener with "where age > 19" and client 2 registers the CQ listener with "where name = emmanuel". The filter knowing for which client it filters, it will be able to only return the keys that match the query. Another useful but not fundamental notion is the ability for a client to enlist the same filter id / converter id tuple with different parameters. The same client might be interested in several different queries. BTW have you considered some kind of multiplexing mechanism in case the several client listeners on the same client are interested in the same event? Emmanuel On Thu 2013-12-05 17:16, Galder Zamarreño wrote: > Hi all, > > Re: https://github.com/infinispan/infinispan/wiki/Remote-Hot-Rod-Events > > Thanks a lot for the feedback provided in last thread. It was very > constructive feedback :) > > I've just finished updating the design document with the feedback provided in > the previous email thread. Can you please have another read and let the list > know what you think of it? > > Side note: The scope has got bigger (with the addition of > filters/converters), so we might need to consider whether we want all > features in next version, or whether some parts could be branched out to next > iterations. > > Cheers, > -- > Galder Zamarreño > gal...@redhat.com > twitter.com/galderz > > Project Lead, Escalante > http://escalante.io > > Engineer, Infinispan > http://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