Re: [infinispan-dev] Hot Rod - pt3

> > I can see how they can be abused to form a JMS-like message-passing layer, but then a lot of stuff could be open to abuse. 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. Once we have the server->client notification mechanism working IMO we should allow the user to decide which notifications he wants to listen to, and not be restrictive about it. Re:key change notifications, I'm not sure that will work with the current ISP architecture: right now the notifications are local, i.e. one will only be notified by the keys changed in the local cache. So if a used want to be notified when the "account" key changed, that will only happen if he is connected to the server on which the "account" key was hashed. Even more, if he will connect to another server, which contains "account", the notification behavior might be different, which might be confusing. Not a protocol design expert, but is it common for this "push" approach for protocols?