hadoop-zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patrick Hunt <ph...@apache.org>
Subject Re: Contrib section (nee Re: A modest proposal for simplifying zookeeper :)
Date Fri, 27 Feb 2009 08:12:25 GMT
Hi Anthony. We have a contrib in the current release, it's under src. 
I'm not sure I understand, what is "contrib section" referring to? Or do 
you mean client recipe implementations? (like ZOOKEEPER-78, which is 
being worked on for 3.2)

Patrick

Anthony Urso wrote:
> So does this mean no contrib section?
> 
> On Thu, Feb 26, 2009 at 10:00 PM, Patrick Hunt <phunt@apache.org> wrote:
>> So far we've stayed with the process used by core as this minimizes the
>> amount of work we need to do re process/build/release, etc... we just copy
>> the process/build/release etc... used in core, we get all that for free. I'm
>> hesitant to diverge as this will increase the amount of work we need to do.
>> Core has moved to Ivy, we may move to that at some point, but currently
>> we're focused on adding functionality, fixing bugs -- not changing build.
>>
>> Patrick
>>
>> Anthony Urso wrote:
>>> Speaking of the contrib section, what is the status of ZOOKEEPER-103?
>>> Is it ready to be reevaluated now that 3.0 is out?
>>>
>>> Cheers,
>>> Anthony
>>>
>>> On Fri, Jan 9, 2009 at 11:58 AM, Mahadev Konar <mahadev@yahoo-inc.com>
>>> wrote:
>>>> Hi Kevin,
>>>>  It would be great to have such high level interfaces. It could be
>>>> something that you could contribute :) . We havent had the bandwidth to
>>>> provide such interfaces for zookeeper. It would be great to have all such
>>>> recipes as a part of contrib package of zookeeper.
>>>>
>>>> mahadev
>>>>
>>>> On 1/9/09 11:44 AM, "Kevin Burton" <burton@spinn3r.com> wrote:
>>>>
>>>>> OK.... so it sounds from the group that there are still reasons to
>>>>> provide
>>>>> rope in ZK to enable algorithms like leader election.
>>>>> Couldn't ZK ship higher level interfaces for leader election, mutexes,
>>>>> semapores, queues, barriers, etc instead of pushing this on developers?
>>>>>
>>>>> Then the remaining APIs, configuration, event notification, and
>>>>> discovery,
>>>>> can be used on a simpler, rope free API.
>>>>>
>>>>> The rope is what's killing me now :)
>>>>>
>>>>> Kevin

Mime
View raw message