> 1) you are ignoring the result codes in the callbacks, this could get you
> into trouble (say you do a getData on a node that has been deleted ie
> someone changes then immed. deletes the node)
Actually I think I removed that FIXME.
I'll try to fix this now......
Another issue was that the ACL could change.....
What happens when you have a watch and the ACL changes and it's updated?
The question is how do I handle this. Do I have an ACL change exception or
just start returning onData when the node is available again.
This is another reason I wanted to post this as might be a good contrib that
other people could use.
> 2) I'm confused by one of your comments, you mention:
> //read the current value. NOTE that this could easily be a blocking
> //read here but we might as well have one code path.
> zk.getData( event.getPath(), true, this, null );
> however you are using an async API call, what blocking are you referring
> to? If you are ok w/blocking use the synchronous API, your code would be
> simpler (no callbacks!)
Oh.... that was my point. I'm already using callbacks so I an reduce code
this way. :)
> 3) it's possible for your code to get notified of a change, but never
> process the change. This might happen if:
> a) a node changed watch fires
> b) your client code runs an async getData
> c) you are disconnected from the server
Ah.... interesting. So the async getData would never return. Shouldn't the
client try to reconnect to another server and re-read?
Easy enough to fix this I think.
Location: San Francisco, CA