Hello all,

I had an idea as to how we could improve the interface for watches. When
people set watches, they often do so with specific events in mind. For
instance, when I set a watch on a getChildren call, maybe I'm only concerned
with when new children are added. In another case, when I set an existence
watch on a particular znode, maybe I'm only concerned if it is created. This
behavior is mostly recreatable today by retrying the setting of watches
until you are successful in waiting for the right event, but that approach
can lead to coding errors and definitely increases the number of requests
made by the client. On top of this, you are also less likely to capture the
desired event in a timely fashion for a number of reasons:

- For existence watches you need to set the watch for the event you are
interested in (e.g.: created) only when the znode is in the opposite state
(e.g.: deleted). Failure would require checking to see if the node was
actually created (using the czxid), and resetting the watch if not.
- For getChildren watches, to capture only specific events (znodes added),
you would have to create a watch on the list of children and manually parse
for any differences when the watch is fired. Failure would require resetting
the watch.

Not sure of the feasibility on this one since I am woefully not familiar
with the server side of things, but it seems like it could be useful to
have.

Thanks,
Stephen Tyree

Reply via email to