On 03/15/10 05:17 PM, Jordan Brown wrote: > I'm in the process of doing some work that involves an undocumented > option for a service (basically, to revert to legacy behavior if there's > a problem), and am debating whether to declare the property in the > manifest or not. > > Declaring it in the manifest means the user doesn't have to specify the > type, and that gets you type safety and, as long as the user doesn't > specify the type, protection against typographical errors in the > property name. > > 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. > > Thoughts?
See smf_template(5). In particular, the section on "Property visibility". > At the same time, I'd also like it if properties that are declared in > the manifest could not be deleted with svccfg delprop, so that it's not > possible for a user to destroy a property declaration. That would in > turn mean that the software could rely on the presence of the property > and not have to handle the question of what to do if the property isn't > present. > > Thoughts? Templates also let you specify that certain properties or property groups are required. I think the only time we implicitly validate services against their templates is when they are imported. One interesting possibility might be for the restarter to perform a validation when refreshing a service, and to proactively put non-conforming services in maintenance. Dave
