The first step towards making it easier to configure (and making it
easy to make it easier to configure) OpenSolaris is to provide a
means of describing the lowest-level of configuration data.
In an smf(5) service manifest, we have already carved out a region
for holding service metadata called the "template". It currently
only holds things like man/web page references and a localizable
service name. We've long hoped to grow this section to encompass
more information.
One of the neat things we were able to do with the Visual Panels demo
was provide automatically-generated panels for services that put
configuration in SMF. One of the first things you'd notice when
using it, though, is that you had to decipher whatever arcane names
the service author chose for the service's properties. In most cases
these names are documented in a man page, and we happened to also
provide ready access to the man page, but flipping between
documentation and configuration is tedious. We can and should give
better context in this situation.
To help solve this problem, we've assembled a set of enhancements to
SMF service templates. These annotations let us do things like
specify human-readable names and descriptions for properties and
values, let us indicate when a property isn't something a user should
see or modify, let us put some basic constraints on the values a
property can take on, and do so in a way that can be wildcarded
across classes of property groups, services, or instances.
You can read all about these extensions, and see some examples of how
they are used (no demos, though), at:
http://www.opensolaris.org/os/project/vpanels/templates/
Please let us know what you think.
Dave
