No subject
Tue Jun 01 16:08:38 2004
Return-Path: xorp-cvs-admin@icir.org
Delivery-Date: Tue, 01 Jun 2004 16:09:01 -0700
Received: from wyvern.icir.org (wyvern.icir.org [192.150.187.14])
by tigger.icir.org (8.12.9p1/8.12.8) with ESMTP id i51N91NG054467
for <atanu@tigger.icir.org>; Tue, 1 Jun 2004 16:09:01 -0700 (PDT)
(envelope-from xorp-cvs-admin@icir.org)
Received: from fruitcake.icsi.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11])
by wyvern.icir.org (8.12.9p1/8.12.8) with ESMTP id i51N91PA087850
for <atanu@icir.org>; Tue, 1 Jun 2004 16:09:01 -0700 (PDT)
(envelope-from xorp-cvs-admin@icir.org)
Received: from fruitcake.icsi.Berkeley.EDU (localhost [127.0.0.1])
by fruitcake.icsi.Berkeley.EDU (8.12.10/8.12.9) with ESMTP id i51N91Yq017926;
Tue, 1 Jun 2004 16:09:01 -0700 (PDT)
Received: from wyvern.icir.org (wyvern.icir.org [192.150.187.14])
by fruitcake.icsi.Berkeley.EDU (8.12.10/8.12.9) with ESMTP id i51N8kYq017917
for <xorp-cvs@icsi.berkeley.edu>; Tue, 1 Jun 2004 16:08:47 -0700 (PDT)
Received: from possum.icir.org (possum.icir.org [192.150.187.67])
by wyvern.icir.org (8.12.9p1/8.12.8) with ESMTP id i51N8kPA087847;
Tue, 1 Jun 2004 16:08:46 -0700 (PDT)
(envelope-from pavlin@icir.org)
Received: from possum.icir.org (localhost [127.0.0.1])
by possum.icir.org (8.12.9p1/8.12.8) with ESMTP id i51N8cSI046533;
Tue, 1 Jun 2004 16:08:38 -0700 (PDT)
(envelope-from pavlin@possum.icir.org)
Message-Id: <200406012308.i51N8cSI046533@possum.icir.org>
To: Mark Handley <M.Handley@cs.ucl.ac.uk>
cc: pavlin@icir.org, xorp-cvs@icir.org
Subject: Re: [Xorp-cvs] XORP cvs commit: xorp/rtrmgr/ cli.cc cli.hh
In-Reply-To: Message from Mark Handley <M.Handley@cs.ucl.ac.uk>
of "Tue, 01 Jun 2004 19:55:37 BST." <11011.1086116137@aardvark.cs.ucl.ac.uk>
Date: Tue, 01 Jun 2004 16:08:38 -0700
From: Pavlin Radoslavov <pavlin@icir.org>
Sender: xorp-cvs-admin@icir.org
Errors-To: xorp-cvs-admin@icir.org
X-BeenThere: xorp-cvs@icir.org
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:xorp-cvs-request@icir.org?subject=help>
List-Post: <mailto:xorp-cvs@icir.org>
List-Subscribe: <http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-cvs>,
<mailto:xorp-cvs-request@icir.org?subject=subscribe>
List-Id: Mailing list for XORP CVS commit messages <xorp-cvs.icir.org>
List-Unsubscribe: <http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-cvs>,
<mailto:xorp-cvs-request@icir.org?subject=unsubscribe>
>
> > Add new "create" configuration-mode command that is used to
> > invoke the xorpsh built-in configuration creation+editing mode.
> >
> > Previously, typing just a template path (e.g., "protocols bgp")
> > would invoke that mode. Now we must use the command "create".
> > E.g., "create protocols bgp" or "create protocols bgp {"
>
>
> Personally I rather liked the old behaviour :-) I agree that the mode
> change entering direct entry mode was confusing. I'd probably have
> solved this by printing a message "[Entering create mode]" or
> something similar.
What I didn't like about the original behavior was that node names
from the template hierarchy were added at the same level as other
commands like "show", "set", etc. E.g., a level at the hierarcy
would look like:
delete Delete a configuration element
edit Edit a sub-element
exit Exit from this configuration level
help Provide help with commands
interface Configure network interface
load Load configuration from a file
quit Quit from this level
In other words, the command "interface" above appears together with
the standard CLI commands. This may create potential name collision
problems: e.g., if your template hierarchy contains somewhere a node
named "load", then this will be a problem if this node name is added
to the CLI hierarchy along with the existing "load" command above.
In addition, by putting everything under the "create" sub-hierarcy
we have much better consistency, because we don't interleave the
default system commands with the template-derived commands/names.
>
> However, given that you've changed it, I thought I should probably see
> what Juniper do. It's not easy to find the right documentation, but
> here it is:
>
> http://www.juniper.net/techpubs/software/junos/junos63/swconfig63-system-basics/frameset.htm
>
> Somehow I must have been rather confused when I coded the old behaviour.
> Basically Juniper use both the "set" and "edit" commands to extend the
> current configuration, as well as to navigate it.
I think that our "edit" is practically same as Juniper's.
What is different between our "set" and Juniper's is that in Juniper
"set" can be used to create new configuration branches (e.g., start
configuring new protocols that weren't in the configuration yet).
In our case, "set" can be used only to set/modify things that are
already in the hierarchy.
On the other hand, the editing-mode we have (i.e., the one that is
now under the "create" command) is something that doesn't exist in
Juniper, and in our case it is the mode we have to use to create new
subtrees in the configuration hierarchy (i.e., configure new
protocols, etc).
> Now, the current solution with "create" is definitely workable. But
> it leads to the question of whether we want to be more Juniper-like,
> or whether we're happy with the current solution for this release?
What differentiates us from Juniper is:
* They have two editing commands/modes: "edit" and "set", while we
have three: "edit", "set", and "create".
* Juniper's "set" mode is the union of our "set" and "create":
i.e., in Juniper you can use "set" to set new values or to create
new nodes. In our case we separate those functionalities.
However, our "create" mode provides extra "editor-like"
functionalities that Juniper doesn't.
I have to mention here that last week during the XORP meeting we
(Atanu, Orion and me) discussed briefly those configuration modes,
and we came to the conclusion that our "create" mode behaves
differently from anything Juniper has hence it deserves to be
separate.
Hence, I believe the only question remains whether we should modify
our "set" mode to support creating of new subtree branches (as
Juniper does), which of course will duplicate some of the
functionalities of our "create" mode.
My guess is that this won't be a trivial few-lines change.
Pavlin
_______________________________________________
Xorp-cvs mailing list
Xorp-cvs@icir.org
http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-cvs