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.
Patrick
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 [mailto:ph...@apache.org]
Sent: Tuesday, October 13, 2009 5:03 PM
To: zookeeper-user@hadoop.apache.org
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
the
* 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:
https://issues.apache.org/jira/browse/ZOOKEEPER
Thanks for the report!
Patrick
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
not
sure whether 0 should've been defined or z.state should've returned
something else.
Steven
