> I have a very strong feeling against more complex operations in the ZK server.
Can you please describe a little better what that feeling is about?
> These are things that should be provided by a ZK client helper library. The
Which things should be provided by client helper libraries? Client
libraries cannot provide atomic operations, which means that the
reasoning and logic which must happen on top of ZK to avoid
half-initialized states and observation of structure set up and tear
down must continue to be taken in account. It basically means that to
avoid having a relatively simple batch operation, the reasoning which
must happen around ZK gets significantly more complex, or has to be
> zkclient library from 101tec for example gives you exactly that.
It's not clear to me what "exactly that" is in this context. I've
looked for the code and couldn't find an answer/alternative to the
issues discussed in this thread.
> If you're planning to write another layer on top of the ZK API please have a
> look at https://issues.apache.org/jira/browse/ZOOKEEPER-835
Looked there as well. Also can't find anything relative to this discussion.
> I'm planning to provide an alternative java client API for 3.4.0 and would
> then propose to deprecate the current one in the long run.
> You can preview the new API at
And this is a full branch of ZK. Tried checking out the commit
messages or something to get an idea of what you mean, but also am
unable to find answers to these problems.
If you actually have/know of solutions for the suggested problems
which were not yet covered here, I'm very interested in knowing about
them, but will need slightly more precise information.