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
