Hartmut Lang 2012-02-24, 11:02
Henry Robinson 2012-02-27, 02:31
Patrick Hunt 2012-02-27, 23:43
I understand you concern about backward compatibility.
Currently we have in the CLI two different ways to handle optional
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
"get path watch" and "get -w path". And later we could remove the old style.
What do you think?
Am 28. Februar 2012 00:43 schrieb Patrick Hunt <[EMAIL PROTECTED]>:
> 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
> On Sun, Feb 26, 2012 at 6:31 PM, Henry Robinson <[EMAIL PROTECTED]>
> > 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
> > 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
> > commands.
> > I would open a JIRA for each of the changes you want to work on, and we
> > discuss their merits there. I've commented briefly on each proposal
> > On 24 February 2012 03:02, Hartmut Lang <[EMAIL PROTECTED]>
> >> Hi,
> >> i started to look into the CLI code of zookeeper, and think of making
> >> 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"
> >> work in the same way?
> >> Some changes (like introducing [-v version] or [-w]) will not be
> >> compatible.
> >> Any comments welcome.
> >> /Hartmut
> > --
> > Henry Robinson
> > Software Engineer
> > Cloudera
> > 415-994-6679
Patrick Hunt 2012-02-28, 17:43