[Xorp-hackers] Cli style guide draft

[Eddie Kohler]

> I thought about that. At first I think that making exceptions is bad 
> style - if to use it in command strings, then everywhere. But I don't see 
> need for that. As general rule if user is going to change timers, he/she 
> has to have exact knowledge what's he/she is doing and therefore has to 
> know units as well. Mostly commands speak for theirselves - you wouldn't 
> expect interpacket-delay specified in seconds? ;)

Not a great argument; I might expect it to be specified in MICROseconds.

> There are some cli's which are using msec rarely if they are moving timers 
> from seconds to milliseconds - ie. there is old command "some-timer" and 
> the new one "some-timer-msec". 

This is a really strong argument for explicit units.

> But most implementations just adjust value 
> in such cases during upgrade (that's why it's good idea to have version 
> info in the configuration file ;).

There is no way to version peoples' brains.

>> But there is a better answer, which is to introduce types for time in
>> seconds and time in milliseconds and allow people to actually enter
>> unit suffixes, as in "set ... interpacket-delay 100msec".  FWIW, Click
>> time units are now entered this way; it was a really good change.
> 
> I don't think that it's good idea either. If, then only representation 
> should have it - it would be really annoying to type sec/msec. And it 
> introduces complexity in cli. And it would make value string in cli (at 
> least for now) and it would make sanity checking much harder etc.

It is not really annoying to type "s" or "ms" (which are also reasonable 
abbreviations); and as in Click a straight integer could default to "s", 
leaving "ms" for the uncommon case.  Also "much harder" is an exaggeration. 
But I'm done here.  If the values are left as straight integers, without even 
the possibility of units, then I advocate leaving non-seconds time units as 
"-msec".

Eddie