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