On Fri 2013-12-20 12:09, Dan Berindei wrote: > On Thu, Dec 19, 2013 at 8:43 PM, Emmanuel Bernard > <emman...@hibernate.org>wrote: > > > On Thu 2013-12-19 19:57, Dan Berindei wrote: > > > On Thu, Dec 19, 2013 at 2:15 PM, Emmanuel Bernard < > > emman...@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? > > > > > I was referring to the condition string: "where age > 19", or "where name > = emmanuel".
OK. I am not sure that the fact that the parameter is a string in both cases and that there is only one parameter and not multiple is particularly relevant to the general problem at hand. _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev