David Bustos writes: > Quoth James Carlson on Thu, Jan 22, 2009 at 05:11:10PM -0500: > > > I expect it to age well because there are always users behind > > > modifications, and so each modification should be able to be classified > > > into a customization or a default. > > > > Is generic.xml a "customization" or a "default"? How about > > platform.xml? Or an applied profile? > > generic.xml and platform.xml are defaults because they are written by > service authors. A profile applied by "svccfg apply" is a customization > because it was invoked by an end-user.
Yes, I get the distinction that you're making, but to me (a user) it seems more arbitrary than that. Both of those other profiles are just profiles, and ones I apply by hand (or by script) are rather different from poking around with individual "setprop" tricks. An obvious usage case: I set up profiles to employ for different usages within my data center. I have one called "webserver.xml" and perhaps another called "testmachine.xml". When I list out customizations and I'm using these "standardized" profiles, I'm likely really asking whether there's anything locally different on this one machine, and not asking to see my known profile regurgitated back to me. > > I think that's a bit arbitrary and potentially very confusing, > > especially since one of the (many?) initial users of these things will > > be NWAM, which will almost certainly be playing around with > > automatically applied profiles. Those things aren't "customizations," > > but rather states of the system (or the effects of being in certain > > states). > > If they were specified by an end-user, then they are customizations. If > they were specified by a service author, they are defaults. I suspect > you're talking about the ability to have different defaults or > customizations in different contexts. I don't think that changes > whether they're customizations or defaults, though. I see applied profiles as being potentially quite different from individual customizations. > > One possibly interesting result is that an inexperienced user who > > uninstalls the software and then reintalls it (hoping, perhaps, to get > > a blank slate to "try again") will be surprised. > > Right, and if we can get the packaging system to tell us whether > a manifest is being removed due to a package upgrade or a package > removal, we might be able to make better decisions. Yep. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
