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
_______________________________________________
networking-discuss mailing list
[email protected]
