All, Having now read and thought about the template extensions proposal, I wanted to offer some review comments in terms of things I'd like to see addressed in the next revision of the spec. (If you haven't see the proposal, it is at: http://opensolaris.org/os/project/vpanels/templates/) Overall I like what is being proposed here and like the design. Here are my comments:
1. Clearly there is a set of constraints around the kinds of templated attributes that can be applied to various properties. The spec needs to clarify how the constraints will be represented and enforced. In terms of representation, it would be ideal if it was done as a template itself. In terms of implementation, I assume the plan is that libscf or some new library does the processing for me, provides some reasonable API, and handles the validation. That should be clarified and the API described. Also, I'd like to see the set of constraints, regardless of these details, described in some formal fashion. e.g. a <range> isn't value for a property of type boolean, but is valid for types ... etc. 2. I assume it's entirely the responsibility of a front-end to utilize the <valueset> mechanism to either select a value or confirm that a value is a member of a valueset. Today, scf_value_set_from_string() provides primitive validation of the basic types. I assume that it will *not* do any <valueset> validation -- the front end will do that. Is that correct? If not, explain. In either case, clarify the expectations. 3. The document needs to clarify how the template extensions map on to the property group namespace. As I told some of you earlier, my view is that the current design whereby property group (foo, application) cannot coexist with property group (foo, framework) is broken, and these extensions will exacerbate the situation terribly. I would suggest we permit property groups of differing types to have the same name, and thus templates on a given property group can have the same name with a different type. 4. It isn't clear whether <grouping> and <hidden> are complementary or conflicting attributes. Assume I have property groups G1, G2, ... GN. If I have a set of <grouping> elements which name one or more properties from G1 .. GN, does this imply that other properties are <hidden>? In other words, it seems like there are two models: one says that every group of type 'application' is to shown except for <hidden> members. The other model says that the explicit layout is controlled by <grouping>. My question is whether we want to support both and whether both can be present simultaneously. Personally I feel that the <grouping> model is much more sensible, and if someone is going to take the time to set up these templates they should just do that. And therefore I would get rid of <hidden> entirely -- i.e. everything is visible unless you group. But other choices are possible. In any case, this should be clarified. Look forward to the next update on this feature, -Mike -- Mike Shapiro, Solaris Kernel Development. blogs.sun.com/mws/
