[Xorp-hackers] Cli style guide draft

[Pavlin Radoslavov]

> Hasso,
> 
> I think this is a very strong proposal!

Ditto.

> One comment in terms of usability.  While I agree that getting rid of units 
> from node names, it becomes problematic when different nodes with the same 
> nominal unit (like time) have different scales (msec vs. sec).  That kind of 
> thing is extremely easy to forget, and will really bite people.  I'm thinking of
> 
> interpacket-delay    ... (msec)
> request-interval     ... (sec)
> triggered-timer-max  ... (sec)
> triggered-timer-min  ... (sec)
> ....
> 
> If interpacket-delay is the only one in msec, maybe it SHOULD take -msec in 
> the node name to make that explicit.
> 
> 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.

On one hand I think this is a very good idea, given that we use time
values in many places.
Implementation-wise, for example we already support mac/macaddr type
in the rtrmgr templates and the XRLs, so it won't be terrible
difficult to add support for timeval type (or whatever name we
choose). We could easily support more than one ways of representing
the time. E.g.:

* 1  (= 1 second)
* 1.234567 (= 1s 234ms 567us)
* 1s, 1sec ( = 1 second)
* 1ms, 1msec ( = 1 millisecond)
* 1us (= 1 microsecond)


On the other hand, majority of the time values we use for protocol
configuration purpose are in seconds, and (off the top of my head) I
cannot think of an example (within the set of protocols we support
so far) where we want to represent time value that has seconds and
ms/us component, so the above flexible format might be an overkill.


Stylistically-wise, I'd prefer that we introduce the new timeval
type, because it is cleaner and self-explanatory (e.g., I don't need
xorpsh access with the help strings to figure-out the time units).

Pragmatically-wise, we might be the only routing "vendor" that
support/use such time format so I won't be surprised if this creates
some confusion to the users.

Any other opinions/preferences on the subject?

Pavlin