* Peter Memishian <peter.memishian at sun.com> [2006-09-27 01:11]: > > > No, I think it's a good idea. I was merely communicating the fact that > > svccfg was written to be the bare-bones low-level interface to the > > repository. Unfortunately, in lieu of a higher-level interface, it has > > become the only customizing interface, which is why people find it > > deficient. > > Understood. > > > High-level functionality needs to be somewhere. We'd prefer it be in > > "Visual Panels" ( http://opensolaris.org/os/project/vpanels ), but that > > may be far enough off or so high-level as to call for some high-level > > functionality in svccfg itself. I believe such is being contemplated as > > part of the aforementioned "Templates" project. > > 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? - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems stephen.hahn at sun.com http://blogs.sun.com/sch/