On Dec 19, 2013, at 1: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. Well, it's remote execution of a condition, which is a type of code :) >From Hot Rod perspective, until remote code execution is in place, we could >add a list of N byte[] that are treated as parameters for the filter, and the >filter deciphers what those mean. So, in your case, there would be only 1 >parameter, a byte[], and it would be unmarshalled by the filter into "where >age > 19". If multiple clients add the same parameter, we could use the same >filter instance, that's assuming equality can be calculated based on the >contents of the byte[] by Hot Rod. WRT your suggestion to activate/deactivate the continous query on the fly, can't we achieve that with registration/deregistration of listeners? Or are you trying to avoid all the set up involved in sending the listener registration stuff around? Adding activate/deactivate would require two new operations. Cheers, > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Galder Zamarreño gal...@redhat.com twitter.com/galderz Project Lead, Escalante http://escalante.io Engineer, Infinispan http://infinispan.org _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
