On Dec 13, 2013, at 5:08 PM, Emmanuel Bernard <emmanuel(a)hibernate.org> wrote:
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.
I think the two are fairly tight in, so I think that might be a good idea.
Should filter / converter impls have a @FilterId() / @ConverterId or
should even the id be configured as late binding?
That falls into the configuration part which I hoped @Tristan would provide some insight
on how we'd plug these filter/convert impls into the server. If they're defined
via Infinispan configuration, the ID could be provided via there. If they're found via
service loader pattern, annotations could be used, or callback methods. The former is
probably more elegant.
== 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.
Event data is a byte[] as formatted by the converter on the server side. On the client
side, I can only expose this as is, as byte[]. The callback would then need to disect it
somehow.
The K in RemoteCacheEntryCustomEvent<K> should be removed really, since with these
custom event calls, there's no key provided.
== 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.
This all sounds a bit like remote code exectution to me? You're asking for the client
to pass some kind of executable thing that acts as a filter. That's a separate feature
IMO, which I believe @Tristan is looking into. Once that's in place, I'm happy to
enhance stuff in the remote event side to support it.
From a remote event support perspective, server side static
filter/converters is as far as I'd like to take it.
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?
If they're in the same client, they'd have the same source ID, so just sending it
once would be doable, assuming they're not using different converters.
Cheers,
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
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
galder(a)redhat.com
twitter.com/galderz
Project Lead, Escalante
http://escalante.io
Engineer, Infinispan
http://infinispan.org