I understand you concern about backward compatibility. Currently we have in the CLI two different ways to handle optional arguments. 1. Use options flags like: "create [-s] [-e] path data acl" This is what i would prefer. 2. Use optional parameters: "get path [watch]" This i'd like to change to "get [-w] path" Or change "set path data [version]" to "set [-v version] path data"
In general i think using the posix-like option-flags would give the CLI a more consistent way of usage. Of course for some time we could support both styles. So you would be able to do: "get path watch" and "get -w path". And later we could remove the old style. What do you think? Hartmut Am 28. Februar 2012 00:43 schrieb Patrick Hunt <ph...@apache.org>: > Actually we have been trying to maintain backward compatibility on > user facing features, including cli. For example > https://issues.apache.org/jira/browse/ZOOKEEPER-1326 was implemented > to maintain b/w compat. It's possible to use the CLI in scripts and > often people automate processes using it. I'd suggest we try hard not > to break things unless absolutely necessary, and then perhaps we > should introduce a new "CLI2" or somesuch, with the original CLI > listed as "deprecated", and then cli1 removed in some later version? > I'd rather not see us break b/w compatibility but perhaps others feel > differently? > > Patrick > > On Sun, Feb 26, 2012 at 6:31 PM, Henry Robinson <he...@cloudera.com> > wrote: > > Hi Hartmut - > > > > Great! Any improvements to the CLI are most welcome. > > > > Compatibility *is* a concern; although I don't think we view the CLI as > an > > API that we have to maintain, we shouldn't go changing it without a good > > reason. This applies really only to your proposal to change the syntax > for > > commands. > > > > I would open a JIRA for each of the changes you want to work on, and we > can > > discuss their merits there. I've commented briefly on each proposal > below. > > > > On 24 February 2012 03:02, Hartmut Lang <hartmut.l...@googlemail.com> > wrote: > > > >> Hi, > >> > >> i started to look into the CLI code of zookeeper, and think of making > some > >> contributions there. > >> > >> My ideas: > >> - use commons-cli for option parsing (see: > >> ZOOKEEPER-271<https://issues.apache.org/jira/browse/ZOOKEEPER-271> > >> ) > >> > > > > Sounds good. Feel free to start work on this one! > > > > > >> - switch to options instead of args: like -w instead of [watch] or -v > >> version instead of [version] > >> - use a -s option if you want to see Stat of a command > >> - we could also do a "rm [-r]" instead of "delete" and "deleteall" (see: > >> ZOOKEEPER-1326 <https://issues.apache.org/jira/browse/ZOOKEEPER-1326>) > >> > > > > This is probably ok, but the only potentially incompatible change. > What's a > > compelling reason for doing this? > > > > > >> - order the result of a "ls" command > >> - order the list of available commands > >> > > > > These sound fine. File a JIRA? > > > > > >> - introduce own Class for every command, to be more flexible in adding > >> removing commands > >> > > > > Yep, it would be nice to sort out that giant if-then-if-then block in > > ZooKeeperMain. File a JIRA? > > > > Thanks, > > Henry > > > > > >> > >> To you think this could be a valid contribution to the project? > >> What about compatibility? Is it important that all the "current" > commands > >> work in the same way? > >> Some changes (like introducing [-v version] or [-w]) will not be > backward > >> compatible. > >> > >> Any comments welcome. > >> > >> /Hartmut > >> > > > > > > > > -- > > Henry Robinson > > Software Engineer > > Cloudera > > 415-994-6679 >
