[Xorp-hackers] Cli style guide draft

[Robert Bays]

I would vote for Hasso's proposal of having timevals as u32, with no 
units in the keyword or value.  The help should contain a reference to 
the correct scale.  Just make sure there is a valid allowed range for 
the value and let the underlying module interpret it.

Cheers,
Robert.

Pavlin Radoslavov wrote:
>> 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
> 
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers@icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers