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 <mmarkus(a)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 <dereed(a)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 <galder(a)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
>>>> galder(a)redhat.com
>>>>
twitter.com/galderz
>>>>
>>>> Project Lead, Escalante
>>>>
http://escalante.io
>>>>
>>>> Engineer, Infinispan
>>>>
http://infinispan.org
>>>>
>>> Cheers,
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev(a)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(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
galder(a)redhat.com
twitter.com/galderz
Project Lead, Escalante
http://escalante.io
Engineer, Infinispan
http://infinispan.org
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev