> 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.


Founder/CEO Spinn3r.com
Location: San Francisco, CA
AIM/YIM: sfburtonator
Skype: burtonator
Work: http://spinn3r.com

Reply via email to