Just one high level question, the forms where you don't need to pass in the watcher instance, that would tend to allow people to break recipes by killing watchers out from under the recipe? If so... should the recipes have a way to be notified this happened and potentially re-establish watches?
On Tue, Nov 25, 2014 at 11:52 PM, Cameron McKenzie <[email protected]> wrote: > 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 >
