David John Burrowes wrote:
...
> 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.
One suggestion that occurred to me is to model and call them "security
tokens", or perhaps just "tokens". This might help provide the an
object, as opposed to a property, model, and therefore avoid the
conflict. I haven't tried to map it out, though.
Dave
_______________________________________________
networking-discuss mailing list
[email protected]
