> > 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"
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. :-(
> > 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.
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*.
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.
> > 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?
I think so. No change.
> > 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.
Oh. Now I read the section in your document about secure properties and
I understand that a bit better.
> > 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.
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".
To my eye, the subcommands are conveying two contradictory messages. On
the one hand, the subcommands create* and delete* are generally used to
manipulate 1st class objects (things that are also show-ed, and list-ed,
and sometimes have parent or child objects, and that potentially have
properties).
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).
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".
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).
david
This message posted from opensolaris.org
_______________________________________________
networking-discuss mailing list
[email protected]
