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. _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
