<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Dec 20, 2013 at 12:20 PM, Emmanuel Bernard <span dir="ltr"><<a href="mailto:emmanuel@hibernate.org" target="_blank">emmanuel@hibernate.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Fri 2013-12-20 12:09, Dan Berindei wrote:<br>
> On Thu, Dec 19, 2013 at 8:43 PM, Emmanuel Bernard <<a href="mailto:emmanuel@hibernate.org">emmanuel@hibernate.org</a>>wrote:<br>
><br>
> > On Thu 2013-12-19 19:57, Dan Berindei wrote:<br>
> > > On Thu, Dec 19, 2013 at 2:15 PM, Emmanuel Bernard <<br>
> > <a href="mailto:emmanuel@hibernate.org">emmanuel@hibernate.org</a>>wrote:<br>
> > ><br>
> > > > On Thu 2013-12-19 9:46, Galder Zamarreņo wrote:<br>
> > > > > > == Example of continuous query atop remote listeners<br>
> > > > > ><br>
> > > > > > Thinking about how to implement continuous query atop this<br>
> > > > > > infrastructure I am missing a few things.<br>
> > > > > ><br>
> > > > > > The primary problem is that I don't want to enlist a filter id per<br>
> > > > > > continuous query I want to run. Not only that but I'd love to be<br>
> > able<br>
> > > > to<br>
> > > > > > add a continuous query on the fly and disable it on the fly as<br>
> > well per<br>
> > > > > > client. For that filters and converters are not flexible enough.<br>
> > > > > ><br>
> > > > > > What is missing is the ability to pass parameters from the client<br>
> > to<br>
> > > > > > the remote filter and remote converter. Parameters should be<br>
> > provided<br>
> > > > > > *per client*. Say Client 1 register the continuous query listener<br>
> > with<br>
> > > > > > "where age > 19" and client 2 registers the CQ listener with "where<br>
> > > > name<br>
> > > > > > = emmanuel". The filter knowing for which client it filters, it<br>
> > will<br>
> > > > be able to only<br>
> > > > > > return the keys that match the query.<br>
> > > > ><br>
> > > > > This all sounds a bit like remote code exectution to me? You're<br>
> > asking<br>
> > > > for the client to pass some kind of executable thing that acts as a<br>
> > filter.<br>
> > > > That's a separate feature IMO, which I believe @Tristan is looking<br>
> > into.<br>
> > > > Once that's in place, I'm happy to enhance stuff in the remote event<br>
> > side<br>
> > > > to support it.<br>
> > > ><br>
> > > > I don't think you are correct.<br>
> > > > This is not remote execution in the sense of arbitrary code driven by<br>
> > > > the client. Remote execution will likely be triggered, render a<br>
> > > > result and stop. It will not send matching events in a continuous<br>
> > fashion.<br>
> > > > Plus remote execution will likely involve dynamic languages and I'm not<br>
> > > > sure we want to go that route for things like continuous query.<br>
> > > ><br>
> > ><br>
> > > To be clear, this is exactly the same as the filter parameters that Radim<br>
> > > was asking for, right? From Infinispan's point of view, the filter just<br>
> > > takes a String parameter, and the fact that that string can be parsed by<br>
> > > the filter in a particular language is irrelevant.<br>
> ><br>
> > Not sure what string you are talking about. The filterid?<br>
> ><br>
> ><br>
> I was referring to the condition string: "where age > 19", or "where name<br>
> = emmanuel".<br>
<br>
</div></div>OK. I am not sure that the fact that the parameter is a string in both<br>
cases and that there is only one parameter and not multiple is particularly relevant<br>
to the general problem at hand.<br>
<div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div><br></div><div>I don't think so either, I was just asking if you think there is any difference between what you're asking for and what Radim was asking for...<br>
<br></div></div></div></div>