I quite like this idea, as we're currently doing something similar (given that I understand your suggestion correctly), albeit with the LeaderLatch.
In our case, each node sets a watch on each latch znode and populate/change a local “cache” (more like a registry) when the children of a latch znode change (but only if it’s possible to actually get a leader from LeaderLatch#getLeader()). I suppose it would also be possible have a non-static method that fulfils the same purpose as well, no? On Tue, Jun 3, 2014 at 4:07 AM, Jordan Zimmerman <[email protected] > wrote: > Would it be wise to add something like “public static void > watch(CuratorFramework,String path,AcquisitionListener cw,…)” to each of > these classes to achieve this behavior inside the library in a way that is > consistent with the implementation of each recipe? I know it is an > additional contract to support, but I think it would add value. > > I think adding methods to the various classes would be the best approach. > You might be able to have a general contract via an interface that each of > the recipes implements with a common listener interface. > > > -JZ > -- Mathias Söderberg Software Developer, Burt www.burtcorp.com Cell: + 46 762 79 57 55 | Skype: mthssdrbrg http://twitter.com/mthssdrbrg | http://twitter.com/burtcorp ––––––––––––––––––––––––––––––––––––––––––– The Analytics Platform for Online Media
