David, thanks for your contributions, and apologies if my edits have unintentionally omitted any crucial arguments on your part.
> 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 am inclined to agree. > 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? Unfortunately, this would be tricky since "-p" is already used today (e.g., "dladm show-link -p bge0" > 2) CLIP encourages these names for property-related subcommands: > [ ... ] > > 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. Thanks. > 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. While I can understand the rationale, I fear that having "show" for some subcommands and "get" for others becomes confusing in its own right. > 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. So you are proposing no change to the current specification in this regard, correct? > 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. Actually, they are name/value pairs -- but you're not allowed to look at the value. > 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!) It's not driven by a standard, and we can call them something else if someone can come up with a good name. Conceptually, they are an abstraction for interacting with a "secret" piece of data without having to know its secret value. They could represent passwords, keys, and so forth. -- meem _______________________________________________ networking-discuss mailing list [email protected]
