Peter,

>  > Just a few minor comments:
>  > 
>  > * 3.1 scan-wifi
>  > 
>  >   How about adding a -w (wide, like /usr/ucb/ps w) switch to display all
>  >   fields, allowing the line to become wider than 80 columns?  This is more
>  >   convenient than having to specify all field names with -o.
> 
> We were planning to support "-o all" to show all the field names (this is
> the same way "zfs list" works).  Is that sufficient?  If so, I will make
> this explicit in the documentation.

sure, it achieves the desired effect.

>  > * 3.5 show-prop
>  > 
>  >   The -p in -p <prop>,... is redundant to specify properties.  It's
>  >   implicit in the subcommand that properties are to be displayed, so -p
>  >   could be dropped (just like zfs get <property> <zpool> or dladm
>  >   show-secprop <secprop>) and becomes available for specifying the parsable
>  >   format (instead of the unintuitive -c).
> 
> Usability studies have shown that multiple operands are problematic
> because people get confused about the order[1] (e.g., "getent hosts foo"
> vs "getent foo hosts").  As such, our UI guidelines strongly advise
> against having multiple operands.

Fully agreed for the getent case ;-( Intuitively, getent <key> <map> would
seem more natural (i.e. put the target last, just as with zfs get and
dladm).  But for the dladm subcommands, <link> is always last (if present
at all), so this seems to be consistent and easy to remember/deal with.  My
zfs get example seems to demonstrate that this may work well.

> We have the choice of making the property be the operand instead (and the
> link be the "option"), but I was concerned that:
> 
>      * It would be inconsistent with other dladm link-related subcommands,
>        which always take the link as an operand.

Indeed, this would introduce a confusing inconsistency (as does the use of
-c instead of the common -p).

>      * It suggested the wrong conceptual model: the *-prop commands
>        manipulate a property associated with a link, not vice-versa.

True.

> BTW, I'm guessing you also object to svcprop(1M) :-)

I think I do, although I didn't have to deal much with svcprop lately :-)

        Rainer

-----------------------------------------------------------------------------
Rainer Orth, Faculty of Technology, Bielefeld University

Reply via email to