On 2/15/15 3:41 AM, David G Johnston wrote:
> Otherwise it seems fine but I cannot help but feel that false positives are
> possible; though nothing that doesn't already exist. Mainly, is the change
> going to end up only affect the reset or default value but not the currently
> active value?
I don't understand what you mean by this. We already have the logic to
detect the situation concerned. I'm only extending the reporting. Of
course, if you can think of a case where it doesn't work correctly,
let's hear it.
> Instead of a boolean I'd rather have a string/enum that can capture the fact
> that a reboot is required and the expected outcome. The same field can then
> communicate non-reboot stuff too - like "SIGHUP required" or "session
> scope".
>
> A simple reboot required boolean api could just as easily be done via a
> function; and why limit to just reboots and not reconnection or SIGHUP
> required?
>
> Scope creeping but the reboot case doesn't seem that special overall; other
> than the effort needed to realize the updated value.
It is special because we apply the context restrictions differently in
this case. Normally, when you try to set a parameter that you can't
set, you get an error. But in the case of restart-only, we just ignore
it (and log a message). The point here is to make that more easily
detectable.
What you describe sounds more like that you want to see the complete
stack of overridden and possibly overriding settings. That's a bit of a
different feature, I think.
