[infinispan-dev] Hot Rod - pt3

[Manik Surtani]

On 12 Jan 2010, at 11:16, Galder Zamarreno wrote:

> 
> 
> 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?

+1

--
Manik Surtani
manik at jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org