Mailing-List: contact zookeeper-user-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: zookeeper-user@hadoop.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <498B4120.8060801@apache.org>
Date: Thu, 05 Feb 2009 11:42:24 -0800
From: Patrick Hunt <phunt@apache.org>
User-Agent: Thunderbird 2.0.0.19 (X11/20090105)
MIME-Version: 1.0
To: Patrick Hunt <phunt@apache.org>, Chris Darroch <chrisd@pearsoncmg.com>
CC: zookeeper-user@hadoop.apache.org
Subject: Re: ZooKeeper 3.1 and C API/ABI
References: <4989EC0B.9020400@pearsoncmg.com>
 <498A36EE.7040308@pearsoncmg.com> <498B2900.4090101@pearsoncmg.com>
 <498B341F.1040800@apache.org>
In-Reply-To: <498B341F.1040800@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Chris, please take a look at the patch on 293 asap and let us know if 
you have any issues -- I will be spinning a new release once mahadev/ben 
review and commit the change.

Patrick

ps. I noticed you had some additional suggestions for the c code in 
JIRA, thanks. FYI we do accept contributions from anyone. ;-)


Patrick Hunt wrote:
> Chris, that's unfortunate re the version number (config.h), but I think 
> I see why that is -- config.h should only really be visible in the 
> implementation, not exposed through the includes.
> 
> I've created a JIRA for this:
> https://issues.apache.org/jira/browse/ZOOKEEPER-293
> 
> We'll hold 3.1 for this JIRA, I'll create a new release candidate when 
> the patch is ready. (hopefully today)
> 
> Ben, Mahadev please be available to review/fasttrack this JIRA.
> 
> Patrick
> 
> Chris Darroch wrote:
>> Hi --
>>
>>>> Btw, the version is in the config.h file, generated by autotools, as 
>>>> VERSION. We don't break that out as individual parameters but we can 
>>>> if there is interest.
>>>
>>>    That's useful, I'd missed that.  Thanks; that should work for me
>>> for now.
>>
>>   Sorry ... on second glance, I'll have to retract that.  The problem
>> here is that config.h doesn't get installed by "make install", it's
>> just used by the autoconf stuff.  So there's no simple way that I'm
>> aware of to check the C API version at compile time.
>>
>>   For 3.1.0, I'd suggest either reverting ZOOKEEPER-255 until 4.0.0,
>> or making sure there's at least a way of determining the API version
>> using C macros.  For example, I'd want to be able to do something like:
>>
>> #if ZOO_MAJOR_VERSION >= 3 && ZOO_MINOR_VERSION >= 1
>>    zoo_set(..., stat);
>> #else
>>    zoo_set(...);
>> #endif
>>
>>   Ideally, as I mentioned, until 4.0.0 the zoo_set() functionality
>> would be moved to a zoo_stat_set() or zoo_set_exec() function,
>> and zoo_set() would keep its existing definition but become just
>> a wrapper that invoked the new function with a NULL stat argument.
>> That would be the "APR way", I think, of handling this situation.
>> With the next major version the new function with the extra argument
>> could be renamed back to zoo_set().
>>
>>   It's slightly ugly, I know, if you're thinking of this as a bug
>> which needs to be fixed urgently.  If you're not concerned about
>> backward API compatibility, at a minimum I'd request externally
>> visible macros in zookeeper.h for 3.1.0:
>>
>> #define ZOO_MAJOR_VERSION 3
>> #define ZOO_MINOR_VERSION 1
>> #define ZOO_PATCH_VERSION 0
>>
>>   Thanks,
>>
>> Chris.
>>