Stephen Hahn wrote: > * Peter Memishian <peter.memishian at Sun.COM> [2006-09-27 11:57]: >> > > Well, why not consider stability a low-level feature? That is, why >> would >> > > it be wrong to have the low-level interfaces grok the notion of >> stability, >> > > and (e.g.) require specific flags to modify unstable properties? This >> has >> > > the side effect of forcing all developers to confront and address the >> > > notion of stability when writing their software. >> > >> > Whenever I think about promoting stability in smf(5) from an >> > informational attribute to an active policy, I usually go down the >> > path of suppressing the visibility of less stable levels in the output >> > of svccfg(1M) and svcprop(1). Could you expand on why you think >> > modification alone is a suitable enforcement point? >> >> Supressing visibility by default also seems like a good thing -- but of >> the two sins (showing properties that shouldn't be touched, and allowing >> unstable properties to be modified by default), modification seemed the >> more serious offense and thus I preferred that argument. > > I think I prefer to combine the two; a person is probably looking at > the implementation properties with the intent to change them (possibly > unwisely or as an experiment). > In the case of link configuration, there are at least 3 cases I am concerned about:
1. modifying unstable properties. 2. read-only properties, which can be shown to the administrators. 3. read-only properties, which supposedly should not be shown to the administrators unless for debugging purpose. (for example, link-ids) I'd like to see a solution that handles these 3 cases. Thanks - Cathy
