Making things better is always good.
I have found that in practice, most wrappers of ZK lead to serious errors
and should be avoided like the plague. This particular use case is not a
big deal for me to code correctly (in Java, anyway) and I do it all the
It may be that the no-persistent-watch policy was partly an artifact of the
ZK 1 and ZK 2 situation where ZK avoided keeping much of anything around per
session other than ephemeral files. This has changed in ZK 3 and it might
be plausible to have more persistent watches.
On the other hand, I believe that Ben purposely avoided having this type of
watch to automatically throttle the number of notifications to be equal to
the rate at which the listener can handle them. Having seen a number of
systems that didn't throttle this way up close and personal, I have lots of
empathy which that position. Since I don't have any issue with looking at
for changes, I would tend to just go with whatever Ben suggests. His
opinions (largely based on watching people code with ZK) are pretty danged
On Sat, May 9, 2009 at 12:37 PM, Scott Carey <sc...@richrelevance.com>wrote:
> What I am suggesting are higher level constructs that do these repeated
> mundane tasks for you to handle those use cases where the verbosity of the
> API is a hinderance to quality and productivity.
Ted Dunning, CTO
111 West Evelyn Ave. Ste. 202
Sunnyvale, CA 94086