Hello folks,
I got pointed to this thread because it is talking about some command line
stuff, and because I've been closely involved with some of the efforts at
command line consistency work here at Sun. Sorry my comments are coming so
late in the game.
I'm afraid this paragraph (and maybe the whole message!) may be a bit tedious
for some of you. My perception is that dladm belongs to the SUS/geopt family
of utilities, not the CLIP family. So, on the one hand, CLIP may not be
applicable here. On the other hand, I know of no consistent guidance about how
to deal with properties in the getopt family, and there is guidance in the CLIP
family. So it is useful to at least look at what CLIP says on these points. Our
service processor utilities, for example, have used the CLIP conventions to
help guide design for parts of their family (and in turn helped influence the
CLIP conventions). Put another way, where one family is silent about the
conventions it may be reasonable to borrow existing ideas from another family
(if it can be done compatibly), because this promotes cross-family consistency
(which we want, when possible).
I've seen four issues in this thread:
1) Whether or not to use -p to specify properties (with a related issue of -p
or -c being used to specify parsable output)
2) What to call the subcommand (set-linkprop, setprop-link, set-link-prop)
3) Whether to specify the link as an operand
4) what to do about the security properties subcommands
I hope that's all of the issues. So, here are my comments:
1) CLIP (and it seems svcprop) says you should use -p (though, if the user can
omit -p and the result is unambiguous, the utility may allow that).
Personally, I'm with Seb that I'd be inclined to require the -p for forward
compatability reasons. Independent of that, I'd be strongly inclined to
encourage the use of -p anyway. It has become clear to me in the last year or
so that many utilities in many domains need to get and set properties, and both
CLIP and (last I saw) the service processors are using the -p name=value
syntax. From my vantage point, there's a significant advantage to using this
pattern because I think that as time goes on this will become the expected way
to do this kind of operation.
I recognize this gives you with an evil option (-c) to get parsable output. I
wonder whether you could instead use another option, like -m (Machine parsable)
throughout to reduce the pain?
2) CLIP encourages these names for property-related subcommands:
myutility create -p propname=value newobject
myutility set -p propname=value newobject
myutility get -p propname newobject
myutility unset -p propname newobject
myutility reset -p propname newobject
Words like "set" rather than "setprop" and "set-prop" were chosen mainly for
typing brevity. "set-prop" had the added problem that properties are not quite
"first class" objects, and that noun after the verb in the subcommand tends to
mean the first class object (the operand) being operated on.
At the same time, the CLIP documents don't talk about what to do when the
utility can operate on different classes of objects (which dladm seems to, with
links, devs and aggrs). If your utility can set properties on two different
kinds of objects, what should the subcommands be?
My current feeling is that I think I've seen set-objectprop. (however, when I
take my standards and global consistency hat off and just speak for myself I
think I like setprop-object the best). In any case, I'm going to go talk to
various folks and see if we've got this pattern anywhere and I'll report back
here.
Note one other detail here. By CLIP conventions, the subcommand verbs should
be "get" not "show". "show" is used to get more info about an object than just
its properties.
3) Whether to specify a link as an operand with "set-linkprop". I do think it
should be an operand. We did a usability study a while back on a utility where
we varied the operands based on a different logical model, and it really
confused the users. Folks quickly note and rely on patterns with operands, it
seems.
4) I'm a bit puzzled about the secprop subcommands. These aren't "properties"
in the same way that the link properties are properties. By that, I mean they
aren't name/value pairs. They seem to be keywords or tokens that affect the
whole environment in some way, and they are created and deleted like "first
class" objects. Can you avoid the word "prop" here, or is that being driven by
some standard? (if so, it isn't a pattern I'd want to see generalized!)
Thanks,
David Burrowes
This message posted from opensolaris.org
_______________________________________________
networking-discuss mailing list
[email protected]
