curator-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Drob <mad...@cloudera.com>
Subject Re: ZK 3.5 Removing watches
Date Wed, 26 Nov 2014 14:09:23 GMT
Not a fan of all(), but otherwise I think #5 is fine?

Completely unrelated to your question, but will it be possible to remove
watches recursively?

On Tue, Nov 25, 2014 at 10:52 PM, Cameron McKenzie <cammckenzie@apache.org>
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
>

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