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.