Hi Thomas, > 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 avoided entirely. > 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 > http://github.com/thkoch2001/zookeeper/tree/operation_classes 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. -- Gustavo Niemeyer http://niemeyer.net http://niemeyer.net/blog http://niemeyer.net/twitter
