Hello Tim, Thank you for expressing interest in contributing this code! We have a wiki page that describes the contribution process [1]. We track all work using JIRA, so the first step would be to create a JIRA describing what you are proposing to contribute.
I think we'll need to decide how your work relates to the existing native CLI already in the ZooKeeper codebase [2]. Would you consider adapting your work onto that existing CLI, or do you think it would have to be essentially a rewrite? If the latter, then we'd probably need to give some consideration to the switch to C++. The current native CLI is C. I don't think there is existing precedent for C++ in ZooKeeper, except for contrib modules. I think we'll want to avoid a situation where there are multiple native CLIs shipping in ZooKeeper, in addition to the Java one. The first step is definitely a JIRA though. Technical details like this would get discussed there, and the JIRA would serve as a record of the community's decisions. [1] https://wiki.apache.org/hadoop/ZooKeeper/HowToContribute [2] https://github.com/apache/zookeeper/blob/trunk/src/c/src/cli.c --Chris Nauroth On 12/8/15, 6:58 PM, "Crowder Tim" <timrc...@yahoo.com.INVALID> wrote: >Tangentially related question... > >I have a C++ cli for zookeeper modeled after unix shell. >It has ls (with lots of options including recursive, long, and ACL >listing), >cp, touch, cat, etc. And command/filename completion and history. > >I've secured permission from work (Yahoo) to contribute it. >How do I go about submitting it? > >Thanks! > >.timrc > >-------------------------------------------- >On Tue, 12/8/15, Chris Nauroth <cnaur...@hortonworks.com> wrote: > > Subject: Re: Adding a new API to ZooKeeper 3.4? >(ZOOKEEPER-1962/ZOOKEEPER-2260) > To: "dev@zookeeper.apache.org" <dev@zookeeper.apache.org> > Date: Tuesday, December 8, 2015, 4:24 PM > > Thanks for the response, > Patrick. Considering that, it sounds like > recursive ls is a non-starter for 3.4, but we > can focus on shipping it in > 3.5. I'll > focus on that in the code reviews. > > --Chris Nauroth > > > > > On > 12/8/15, 4:12 PM, "Patrick Hunt" <ph...@apache.org> > wrote: > > >On Tue, Dec 8, > 2015 at 3:01 PM, Chris Nauroth <cnaur...@hortonworks.com> > >wrote: > >> Do we have > any kind of policy regarding adding new public APIs in > the > >>3.4 stable maintenance > release? Adding a new API won't harm > >>backwards-compatibility, but it does > mean that an upgraded client can't > >>use the new API until the server side > gets upgraded too. I'd expect > >>adding a new API is overall OK, subject > to standard risk assessment for > >>any > patch going into a stable maintenance line. > >> > > > >Hi Chris. It's always been the case > that we only allow fixes in fix > >releases. Things like API changes are > always introduced in minor > >releases, and > they need to be backward compatible. Major releases are > >for cases where we need to break b/w compat > (which hasn't happened > >since we > moved to Apache). > > > >Patrick > > > >> ZOOKEEPER-1962 proposes enhancing the > CLI to support recursively > >>listing > children. However, running this on a large tree would > risk > >>hitting the jute.maxBuffer > threshold, consuming a lot of memory, and > >>consuming a thread for a long time to > process the request. I'd like to > >>propose that ZOOKEEPER-2260 (paginated > getChildren) be a pre-requisite > >>for > the CLI enhancement, so that we can avoid these problems. > However, > >>I'd also like us to try > to ship the feature in a future 3.4 release, > >>because it's very useful for > operators. This is the main motivation for > >>my policy question about adding new > APIs in a stable line. > >> > >> --Chris Nauroth > > >
