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?
--
Galder ZamarreƱo
Sr. Software Engineer
Infinispan, JBoss Cache