I think it's a good idea but that's essentially continuous query. My guts tell me you still want the low level plumbing and actual imperative code for additional usecases.
On Fri 2013-12-13 15:51, Galder Zamarreño wrote: > > On Dec 9, 2013, at 6:47 PM, Mircea Markus <mmar...@redhat.com> wrote: > > > Hey Galder, > > > > Another idea that come up today was to use the QueryDSL for specifying both > > the filter and the transformer (the DSL has projection). > > The query DSL builds an HQL string for which one the server side the filter > > can be built on the fly (we already do that with the embedded query DSL). > > There are some nice advantages of doing this: build the filter and the > > listener at runtime, in a language independent manner(assuming query DSL is > > migrated), with an API customers are already used to. > > I'll look into that. Thanks for the heads up. > > Cheers, > > > > > > > On Dec 6, 2013, at 5:38 PM, Dennis Reed <der...@redhat.com> wrote: > > > >> On 12/06/2013 08:52 AM, Mircea Markus wrote: > >>> Some notes: > >>> > >>> "This means that the Hot Rod protocol will be extended so that operation > >>> headers always carry a Source ID field." > >>> - shall we add a new intelligence level to handle this? Besides reducing > >>> the payload, would allow upgrading the java and Cpp clients independently. > >> > >> Instead of a new intelligence level, if the client told the server what > >> features it supports when connecting this could be done more fine-grained, > >> so that a client could support some subset of functionality (instead of > >> being forced to implement the specific extentions in one of the > >> pre-defined intelligence levels). > >> > >> -Dennis > >> > >>> In one of our discussions, you've also mentioned that you'd want to use > >>> the cluster listeners as a foundation for this functionality. That > >>> doesn't seem to be the case from the document, or? Not that it's a bad > >>> thing, just that I want to clarify the relation between the two. Another > >>> way to handle connection management, based on clustered listeners, would > >>> be: > >>> - the node on which the listeners ID hashes is the only one responsible > >>> for piggyback notifications to the remote client > >>> - it creates a cluster listener to be notified on what to send to the > >>> client (can make use cluster listener's filtering and transformer > >>> capabilities here) > >>> > >>> Comparing the two approaches: this approach reuses some code (not sure > >>> how much, we might be able to do that anyway) from the cluster listeners > >>> and also reduces the number of connections required between clint and > >>> server, but at the cost of performance/network hops. Also the number of > >>> connections a client is required to have hasn't been a problem yet. > >>> > >>> One more note on ST: during ST a node might receive the same notification > >>> multiple times (from old owner and new owner). I guess it makes sense > >>> documenting that? > >>> > >>> On Dec 5, 2013, at 4:16 PM, Galder Zamarreño <gal...@redhat.com> wrote: > >>> > >>>> Hi all, > >>>> > >>>> Re: https://github.com/infinispan/infinispan/wiki/Remote-Hot-Rod-Events > >>>> > >>>> Thanks a lot for the feedback provided in last thread. It was very > >>>> constructive feedback :) > >>>> > >>>> I've just finished updating the design document with the feedback > >>>> provided in the previous email thread. Can you please have another read > >>>> and let the list know what you think of it? > >>>> > >>>> Side note: The scope has got bigger (with the addition of > >>>> filters/converters), so we might need to consider whether we want all > >>>> features in next version, or whether some parts could be branched out to > >>>> next iterations. > >>> +1. Can we include the notification ack in the optionals category? > >>> What about leaving these as the last bit to be implemented? If time > >>> allows (not to delay the release) we can add them, otherwise just add > >>> them in future iterations? > >>> > >>> > >>>> Cheers, > >>>> -- > >>>> Galder Zamarreño > >>>> gal...@redhat.com > >>>> twitter.com/galderz > >>>> > >>>> Project Lead, Escalante > >>>> http://escalante.io > >>>> > >>>> Engineer, Infinispan > >>>> http://infinispan.org > >>>> > >>> Cheers, > >> > >> _______________________________________________ > >> infinispan-dev mailing list > >> infinispan-dev@lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > > > Cheers, > > -- > > Mircea Markus > > Infinispan lead (www.infinispan.org) > > > > > > > > > > > > _______________________________________________ > > 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 _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
