James Carlson wrote: > Jordan Brown wrote: >> On the other hand, declaring it in the manifest means that it's visible >> by default through svcprop and svccfg listprop. Since it's an >> undocumented option that users should never have to mess with, that >> seems undesirable. >> >> What I would like would be a way to declare a property to be "hidden", >> so that by default it isn't shown by any of the user interfaces. If >> it's set to a non-default value, then it should be shown. > > Yuck. I think I'd rather see this trait of SMF used to drive a > friendlier administrative model rather than used as an excuse to hide > things from the user. > > In other words, it seems to me that SMF's svcprop and svccfg mechanisms > are very low-level details that administrators ordinarily shouldn't have > to deal with. If the service you are talking about had a customized > administrative interface layered on top, rather than relying on SMF's > internals as a primary interface, then there likely wouldn't need to be > much of a reason to "hide" anything.
Customized administrative interfaces are best, certainly. However, they are also very expensive. Previous Sun management tools have relied on them exclusively, and I believe that is one of the reasons that they have failed - it was too expensive and difficult to add new configurable components and configuration values, and so the UIs became stale. Metadata-driven user interfaces can be pretty good, and far better than manually editing configuration files. A mechanism (like smf_template(5) appears to be) that allows the service developer to declare variables, including type, constraints, and hints on presentation, enables such a metadata-driven user interface. Even with a customized user interface the metadata can help to simplify the implementation; medium-complex configuration interfaces might consist of little more than lists of tabs, each with a list of configuration items. Firefox demonstrates this model. It offers fully-customized user interfaces for the most commonly-used configuration parameters, but for less commonly-used configuration parameters it offers "about:config", which is still tons better than editing prefs.js.
