curator-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cameron McKenzie <cammcken...@apache.org>
Subject ZK 3.5 Removing watches
Date Wed, 26 Nov 2014 04:52:19 GMT
Guys,
I've started looking into this enhancement (CURATOR-161), and was just
looking for some opinions on the fluid style for removing watches.

I was thinking of:

*1.) For removing a single watcher*

curator.removeWatcher(watcher).ofType(watcherType).forPath("/test");

*2.) For removing a single watcher in the background (would support the
normal Backgroundable interface)*

curator.removeWatcher(watcher).ofType(watcherType).inBackground().forPath("/test");

*3.) For removing all watchers of a given type:*

curator.removeWatchers().ofType(watcherType).forPath("/test");

*4.) For removing all watchers of a given type in background:*

curator.removeWatchers().ofType(watcherType).inBackground().forPath("/test");

*5.) Also handling the case where we wish to allow the client to remove its
local watches if it is not connected to the server. This would be supported
with both versions and inBackground()*

curator.removeWatcher(watcher).ofType(watcherType).allowLocalRemoval(true).forPath("/test");
curator.removeWatchers().ofType(watcherType).allowLocalRemoval(true).forPath("/test");

Or is it preferable to combine the top level removeWatcher() /
removeWatchers() into a single call and have the underlying interface
differentiate?

Something like:

curator.removeWatchers().watcher(watcherRef).ofType(watcherType).forPath("/test");
curator.removeWatchers().all().ofType(watcherType).forPath("/test");

I think that the first way reads better, but I guess it clutters up the
CuratorFramework a bit more.

Any thoughts are appreciated.
cheers

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message