[infinispan-dev] Design of Remote Hot Rod events - round 2

[Emmanuel Bernard]

On Thu 2013-12-19 19:57, Dan Berindei wrote:
> On Thu, Dec 19, 2013 at 2:15 PM, Emmanuel Bernard <emmanuel at hibernate.org>wrote:
> 
> > On Thu 2013-12-19  9:46, Galder Zamarreño wrote:
> > > > == 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.
> >
> > I don't think you are correct.
> > This is not remote execution in the sense of arbitrary code driven by
> > the client. Remote execution will likely be triggered, render a
> > result and stop. It will not send matching events in a continuous fashion.
> > Plus remote execution will likely involve dynamic languages and I'm not
> > sure we want to go that route for things like continuous query.
> >
> 
> To be clear, this is exactly the same as the filter parameters that Radim
> was asking for, right? From Infinispan's point of view, the filter just
> takes a String parameter, and the fact that that string can be parsed by
> the filter in a particular language is irrelevant.

Not sure what string you are talking about. The filterid?