Hello Meem,
> > 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 is pedantic in this specific context, and thus aggrivating for the
reasons you mention. At the same time, from the larger perspective,
there are other utilities where using "show-" for properties gets
confusing. So, from that perspective it isn't pedantic, but actually
overall improved experience.
For what it is worth, I've been fishing around existing precedents, and
we have a couple reasonably prominent cases that have gone with
set-linkprop
rather than
setprop-link
I need to verify one other detail, but at the moment I think the former
form brings the most value for consistency (and thus transferablity of
knowledge)
> > 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]".
I didn't necessarily mean to be implying I was recommending "secval".
And I agree that it has some of the same problems.
> Further, I prefer "prop" since these objects are
> semantically similar to properties, not "values".
Yes. I agree with this.
The core issue for me here is just that there is this pattern of
managing properties of objects appearing in varous utilities. These
aren't "create-"ed or "delete-"ed... so your interface simultaneously
matches and contradicts the patterns that other utilities are using. It
still may be worth it for you to cause that bit of confusion because any
other alternative is worse. I don't have a deep enough perspective into
your usage space to be able to comment on that intelligently.
david
This message posted from opensolaris.org
_______________________________________________
networking-discuss mailing list
[email protected]
