Hi Mike, On Sun, Jul 29, 2007 at 06:33:59PM -0700, Michael Shapiro wrote: > The top-level question to ask is whether plug-in configuration is (a) intended > as tunables for administrators or (b) really only for developers or for the > "I'm a Solaris OEM" level of customization. For example, for fmd(1M), I have > a set of plug-ins, but the architecture is entirely oriented around (b). > Therefore, for fmd, plug-in delivery and config is handled entirely outside > SMF. > If your answer is more (a), then property groups is likely the best approach > because you have to control the plug-in namespace anyway, so you can just > mirror that namespace in the property group layout.
Yes, plugin configuration is (a), intended for administrators. I expect they'll be enabling/disabling plugins and changing their configuration as per site policy. > > A second-order question is what is the nature of your configuration data. > SMF works well at encapsulating relatively small amounts of relatively "flat" > data, like a small set of integers, booleans, and strings. Alternatively, if > your configuration data is something more like at 1200-line policy language > input file, then for architectural reasons alone it will need to live outside > of SMF, although in model (a) one could use SMF properties to store the URI > of the location of the policy input file. Now we have like 30 audit classes and even when having extensible classes (64bit representation) the configuration should fit into smf boundaries without a problem. Usually, admins select just few classes for auditing to make the configuration simple and clean. thanks, tomas
