There's no requirement currently that they be the same/similar. We try to keep them similar just to ease the learning curve for ppl that want to use both (also for the devs to stay sane).

In a perfect world, probably. I think there's some divergence just due to the fact that java is OO and c is not (like polluting name spaces and such).

Version 4 will come at some point, we had thought to make some non-bw compatible changes to the APIs in that release (like moving to long for some fields that are currently int's). Perhaps in that release we could address some of the more egregious examples.


Steven Wong wrote:
Java's KeeperState.Disconnected is 0, so probably that's what the C
client should have.

This brings up another question: Is the C client supposed to be in sync
with the Java client? I notice that there are multiple differences
between C's ZOO_*_STATE and Java's KeeperState.

-----Original Message-----
From: Patrick Hunt [] Sent: Tuesday, October 13, 2009 5:03 PM
Subject: Re: C client (via zkpython) returns unknown state

You're right, 0 should be something like "INITIALIZING_STATE" but it's not in zookeeper.h

zookeeper_init(...) docs:
* This method creates a new handle and a zookeeper session that corresponds
  * to that handle. Session establishment is asynchronous, meaning that
  * session should not be considered established until (and unless) an
  * event of state ZOO_CONNECTED_STATE is received.

Please enter a JIRA for this and we'll address it in the next release:

Thanks for the report!


Steven Wong wrote:
Using zkpython with ZK 3.2.1 release:

import zookeeper as z

zh = z.init(...)

z.state(zh)  # returns 3 == z.CONNECTED_STATE

# kill standalone ZK server

z.state(zh)  # returns 0 == ???

The problem is that 0 is not a state defined by zookeeper.[ch]. I'm
sure whether 0 should've been defined or z.state should've returned
something else.


Reply via email to