Re: [infinispan-dev] Hot Rod - pt3

On 01/08/2010 08:26 PM, Alex Kluge wrote: >> Perhaps the events should just be restricted to notifying when a key has changed (i.e., a bit like Invalidation) but with no values/payload passed on, forcing the client to do a GET if the value was required. > > Exactly, we can define the set of events that they can listen for, the end > user only has the choice to subscribe to the events or not. I am most interested in being able to listen for write events. The level of granularity though could use some thought. > > > The granularity of the events has also been a topic of discussion. The end user is likely to want to make the selection at the level of the specific cache, or, perhaps, of keys within a cache. However, I expect that they would be well served with making the selection at the level of the cache, rather than trying to sort out which specific keys they are interested in. > > > Relevant events should be seen no mater which server you are connected to. I am trying to stay away from implementation details, but I can say that I have done this, and that the cost is not that high. Just to make sure we're all in the same page. I don't expect to specify key change related events for the moment. Right now, the primary use case that I see is sending back cluster formation changes, rather than passing this back as part of response. This would allow for clients to subscribe to them depending on their capabilities. However, events will be specified in such way that allow for easy extension for other use cases mentioned. Do we all agree with this?