[infinispan-dev] Design of Remote Hot Rod events - round 2

[Dan Berindei]

On Fri, Dec 20, 2013 at 12:20 PM, Emmanuel Bernard
<emmanuel at hibernate.org>wrote:

> On Fri 2013-12-20 12:09, Dan Berindei wrote:
> > On Thu, Dec 19, 2013 at 8:43 PM, Emmanuel Bernard <
> emmanuel at hibernate.org>wrote:
> >
> > > On Thu 2013-12-19 19:57, Dan Berindei wrote:
> > > > On Thu, Dec 19, 2013 at 2:15 PM, Emmanuel Bernard <
> > > emmanuel at 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.
>
>
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...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20131220/d3c6c772/attachment-0001.html