* 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/

Reply via email to