[EMAIL PROTECTED] wrote:
> Further, I'm still uneasy about the object of the *-prop subcommands
> being links. This is not consistent with the existing dladm(1M)
> usage, where verb and type of object are concatenated to form the
> various subcommand names. With the proposed *-prop options, this
> would imply that the objects are properties are the objects, when the
> objects are really the links.
>
> To be consistent with the current dladm(1M) model, the property
> subcommands should be made specific to the type of objects they
> correspond to, e.g. setprop-link, getprop-link, showprop-link. This
> would be also compliant with the latest CLIP guidelines.
Yes, this is true -- and we also discussed this issue internally. The
consensus was that setprop-link seemed too cumbersome, and that the net
result might be reduced usability (e.g., one can easily see users getting
confused about where to put the dashes or words -- is it set-prop-link,
setprop-link, set-link-prop[1], ...).
If you think that there are issues with the latest CLIP guidelines, they
should be discussed with UIRB, and addressed as part of the
recommendation. Otherwise there's a risk that every command line
interface faced with the same problems will take a different path,
leading to more inconsistencies across the board.
Of course, more discussion on this issue is welcome.
[1] Of course, for an experienced user set-link-prop makes no sense as per
your original point -- but seems completely reasonable for the vast
majority not familiar with the finer points of dladm's user interface.
Indeed, that vast majority is the set that I see preferring set-prop
to setprop-link.
I'm not convinced. You have the risk of designing the interface into a
corner, which could lead to even more inconsistencies down the road,
e.g. defining properties that need to be applied to different types of
objects.
A user already has to understand that the dladm subcommands act on
specific types of objects. Once this is understood, subcommands of the
form setprop-link seem a "natural" fit.
Nicolas.
--
Nicolas Droux, Solaris Networking
Sun Microsystems, Inc. http://blogs.sun.com/droux
_______________________________________________
networking-discuss mailing list
[email protected]
