> > 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.
Sure, we can bring this issue up with UIRB. First, I would like to hear more about what the OpenSolaris community thinks about this issue. > 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. We already have secure properties defined, and there are a set of *-secprop interfaces to deal with them. We could follow the same convention for other 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. I don't find it quite so natural. In particular, all of the existing subcommands (and most proposed subcommands) have a single verb acting on a single object. Here, we have a single verb acting on an object (prop) that is associated with another object (link). -- meem
