That is not the point. Its not about what you can or can't do, its how much code you have to write to do it. And especially how much boilerplate, repeated handling of errors and exceptions.
The base ZK API is too low level for basic tasks and requires a lot of ugly exception handling -- especially the synchronous API. Its all there for a reason, but those reasons don't apply to every use case. 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. ________________________________________ From: Ted Dunning [ted.dunn...@gmail.com] Sent: Friday, May 08, 2009 11:16 PM To: email@example.com Subject: Re: NodeChildrenChanged WatchedEvent You can use the exists() call to get pretty much what you want. On Fri, May 8, 2009 at 7:01 PM, Scott Carey <sc...@richrelevance.com> wrote: > > On 5/8/09 2:15 PM, "Ted Dunning" <ted.dunn...@gmail.com> wrote: > > > There is no gap in time if you put the new watch into the call that gives > > you the current version of the data. That is the point of having the > watch > > argument in all of the get* calls! > > > > There is a gap in time between when watch A triggers, and when the server > gets your next watch setting. From both the server and client point of > view, the watch "ends" when it fires, and there is a gap in time before the > next one begins. > Changes between those times must be inferred by the client. > >