[Xorp-hackers] BG 172

[Eddie Kohler]

Hi Pavlin, from the dumb gallery:

Thanks for this very clear mail.  The completion-based arguments for keeping 
"set" as is aren't very convincing, I think.  This one is tougher:

> * With the new "set" command it becomes unclear whether we are
>   modifying an existing node or creating a new one.
>   To take Patrick's example (Bugzilla entry #172, Comment #2),
>   let say we are using the following two commands:
> 
> set route static route4 10.0.0.0/24 next-hop 172.16.1.1
> set route static route4 10.0.0.0/24 next-hop 172.16.1.2

It is really problematic when code or configuration statements silently change 
meaning from one release to the next!

So, followon question.  Can you enumerate those places in the configuration 
tree that are single-value now, but are likely to become multi-value in 
future?  If so then they could be specially marked so they behave like 
multi-value even now.  That is, if you entered the above statements, you would 
get:

 > set route static route4 10.0.0.0/24 next-hop 172.16.1.1
[OK]
 > set route static route4 10.0.0.0/24 next-hop 172.16.1.2
[ERROR: eventually you will be able to add multiple next-hops for a given
route, but for now, you must delete the old next-hop before setting a new one.]

Does this make sense?

Also, you could also keep "create" around with the current semantics, so the 
user could express the intent to create a new node when appropriate.
Eddie



> 
>   Currently, "next-hop" is a leaf node that can take a single value,
>   hence with the old and the new "set" command we are actually
>   modifying its value. However, lets say we change "next-hop" to
>   be a multi-value node (e.g., along the lines of implementing
>   floating static routes per Bugzilla entry #165).
>   Then with the current "set" command the above two commands are
>   automatically invalidated (you will get a syntax error) so it
>   becomes clear "next-hop" is not a single-value node.
>   With the new "set" the above two commands will be automatically
>   accepted, but just by looking at them it is unclear whether the
>   value of "next-hop" is modified or whether there will be two new
>   nodes "next-hop": "next-hop 172.16.1.1" and "next-hop 172.16.1.2".
> 
> In other words:
> 
> A) With the new "set" command the command-line completion at every
>    level gets expanded to practically everything configurable even
>    if someone wants only to modify an existing value.
> 
> B) Sometimes there will be ambiguity (from user perspective) whether
>    the value of a node is modified or whether a new node is added.
>    This ambiguity can be cleared if you know the structure of the
>    configuration tree (e.g., whether a node is single-value or
>    multi-value) or if you use the "show" command to see the
>    configuration before and after any modifications.
> 
> 
> I don't consider the new behavior as a show stopper, but I want
> people to understand it before we change anything.
> 
> 
> Implementation-wise, if we go with a single "set" command, my
> preference is to do the following:
> 
> 1. Remove current "set", and rename existing "create" to "set".
> 
> 2. Fix Bugzilla entry #330 so we get better command-completion for
>    multi-value nodes.
> 
> [Note: the above two steps are what Hasso already suggests in
> Bugzilla entry #172, Comment #6.]
> 
> 3. Add-back a new "create" command that is just an alias for the new
>   "set" command. I think we would need to keep such alias for a
>    while for backward compatibility purpose until people get used to
>    the new "set" command.
> 
> Comments?
> 
> Pavlin
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers@icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers