Quoth James Carlson on Tue, Mar 25, 2008 at 02:33:47PM -0400: > Note the "given:" this is specifically a reference to a work-around > for the current lack of temporary instance capability. That > work-around involves creating a disabled instance in the repository, > configuring it as desired, then doing a temporary enable on the > instance. > > The weird case I'm pointing out is that if I actually do that, then > odd things can happen if the user tries to enable and disable > services. Specifically, if we have a regular (non-temporary) > instance, and the user does a regular disable (against the > non-volatile repository), and then does a temporary enable, the final > system state is _indistinguishable_ from having a temporary instance. > > It's as though the non-temporary instance suddenly became temporary -- > with all that entails. If we had a boot-time clean-up service (as > some have suggested) for these things, then the configuration would be > wiped away.
Ah yes, that would probably be undesirable. > > > What happens in the reverse case (or is being able to > > > sediment a temporary just an unexpected "feature?")? > > > > Do you mean permanently enabling a temporarily disabled service? Well > > yes, if you choose to interpret temporarily enabled services as > > temporary services, then the user can do that. Is that a problem? > > No, I don't mean that. > > Again, using the work-around described above, if someone creates a > temporary service but then does a temporary disable and a permanent > enable -- perhaps by mistake -- the result is that the "temporary" > instance suddenly becomes permanant. Right -- it's essentially impossible to repurpose standard semantics because you can't instruct the framework not to expose the original semantics through the generic interface. You could instruct users "not to do that", but that would be pretty silly. David
