> Ooh. Outch. :-( > On the other hand, this seems to be for a single subcommand, and if you > use get-* here, the disruption won't be, perhaps, quite as nasty. > Still, it is ugly no matter how one approaches it. :-(
Yes, and given the choice between a bunch of equally ugly choices, I'd rather stick with the one we've already proposed :-) > Oh. Maybe I said something that was misleading. The subcommand for > showing info about links should indeed be "show-link". What I meant to > say is that the subcommands that operate on properties of objects would > be "get*". In general, the subcommands for properties are set* and get*, > while commands that operate on objects are show*. Understood. > This gets a little bit "weird" for things like you've got here: > dladm show-link mylink > dladm get-linkprop mylink > In a case where the link object only has properties and no other info, > then these two subcommands are the same and that's not good. On the > other hand, every case I've seen like this the "link" kind of object has > more info associated with it than just properties, so show-link is > either distinct or a superset of get-linkprop. That's correct. I'm OK with using "get" instead of "show", though in this case I think "show-prop" (or "show-linkprop") is perfectly understandable and that "get-prop" (or "get-linkprop") may sacrifice usability (e.g., because the user has to remember to use "get" rather than "show") for pedantic consistency. > > 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. > > This is interesting. And I guess the right answer here is "how will > users think of these things" or "how do you want users to think of these > things". Yes. > On the other hand, the suffixes "-secprop" imply to me that these are > properties of some object called "sec[urity]" (and the operands should > be those objects). Yes, this is one of the reasons I'm resistant to "-linkprop". > On the third hand (I guess I'm from Mars :-) these are unusual > property-like-things because they've got a class... glancing through > your document, it isn't clear to me if there is a closed set of classes > or whether this is a user definable value. So, you may be in a situation > you need to do something "nonstandard". The user cannot define new classes, but we will be adding more classes to Solaris in the future (e.g., to support the WPA security mode). > My inclination, given that these sound like they don't have an explicit > object that they are properties of would be to tread them as some kind > of special 1st class object. Maybe I'd call them "secure values", > "secure tokens", "protected parameters", "secret arguments" or "shrouded > nuggets" (ok, not that :-), position them somewhere in the user model of > the system as such, and go with the create-, delete-, show-* set of > subcommands (create-secval, etc). I agree with your inclination, but disagree with the suggested name. That is, "create-secval" appears to have the same risks as "create-secprop" -- that someone will think that they are values of some object called "sec[urity]". Further, I prefer "prop" since these objects are semantically similar to properties, not "values". -- meem _______________________________________________ networking-discuss mailing list [email protected]
