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 time.
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 good. 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 DeepDyve 111 West Evelyn Ave. Ste. 202 Sunnyvale, CA 94086 www.deepdyve.com 858-414-0013 (m) 408-773-0220 (fax)
