> > 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. In both cases, the notion of placing the enforcement inside the tools rather than making it part of the API *does* concern me, though. While there may be cases where tools should allow modification or visibility of unstable properties without warning the user, I think those tools should still have to do so consciously -- e.g., by passing the appropriate flags to the underlying library routines. -- meem
