OPTIONS framework bug vs. SSL issues
matthias.andree at gmx.de
Tue Aug 30 11:09:49 UTC 2011
Am 30.08.2011 12:28, schrieb Frank Wall:
> On Mon, Aug 29, 2011 at 11:40:25AM +0200, Matthias Andree wrote:
>> Euhm, while workable I don't like that approach. And I conclude that
>> the way the OPTIONS system currently works has a serious shortcoming, in
>> that it does not report changed defaults to the user.
>> Basically in this situation ("default changed") we'd need to:
>> 1. present the options form again
>> 2. mention to the user that the default has changed
>> 3. let him choose.
> I don't think that this is the right way to go. You are forcing
> the user to rethink his past decision(s). Why would I want to do this?
Because you must, the former default configuration, even if you've
acknowledged it as an informed decision you've made, no longer works.
> The user decided to go a specific path by initially choosing a
> specific set of OPTIONs. We *must* assume that the user had good
> reasons to do so. We should *not* assume the user has no idea what
> he's doing and needs to be guided. The latter would make make the
> update process just more complicated.
The point is, most users just agree to the defaults, and in that
situation, there is reason to re-prompt.
One might argue that we don't need to reprompt if the new default
matches the old configuration, but the OPTIONS framework currently
doesn't know "user set this deliberately" or "user just stuck to the
More information about the freebsd-ports