[prev in list] [next in list] [prev in thread] [next in thread] 

List:       listar-dev
Subject:    [EDev] Some musing about 'double negatives'
From:       Bill Hacker <bill () triligon ! org>
Date:       2004-04-25 15:13:38
Message-ID: 408BD5A2.5030407 () triligon ! org
[Download RAW message or body]

Trial balloon here:


- Suppositions:  (subject to modification)

A) We have had a reasonable explanation for the historical existence of
what has been referred to as 'double negatives' in the config file.

B) They have been cited as non-intuitive, but have never been a
show-stopper.

C) They do seem to give rise to periodic configuration errors - often on
'live' lists, and a need for 'training' for newbies.

D) As the variables/flags <other appropriate nomenclature> in question
are used throughout many modules, and have dependencies, herarchies,
overriding behaviour, etc. - changing them, either all at once or few at
a time is a 'non trivial' exercise at best.  Moreover, a 'non-essential'
exercise. May not be worth doing.

- So - Another Possibility:

IF

- Two 'layers' were to be written to sit on top of the config file.

"Layer ONE" would be a user interface with new 'titles' and revised
explanations for the variables. Perhaps even different grouping/ordering
and layout.  Optional, of course.  *Appears to be* the config file.

Settings might be:

<Succint and intuitive title, bit of functional explanation>

  'activate' (with synonyms 1, on, true, yes, <whatever>

  'deactivate' (with synonyms 0, off, false, no, <whatever>

- Layer TWO would be a script-driven mapping table that converted layer
ONE entries into the *presently existing* config variables as a flat
file w/o comments. Same as present config file - same variables and
flag, same ordering, uncommented.

Rationale <for the apparently pointless bloat>:

- While the config file is *parsed* often, (each cycle) it is almost
certainly *changed* very seldom.  So seldom, that some of us forget the
'proper' interpretations, even <G>.

So - aside from labor and a bit of file space, there is not a lot of
bloat. None at all at runtime, anyway.

- The more intuitive interface *might* reduce errors and inappropriate
'bug reports', waste motion, repetitive discussion - userland mistakes.

- But ALSO:

- Over time, and with no need for a set timeframe, various contributors
  might be able to change the underlying code incremetnally or otherwise
- (if seen appropriate), altering only the version-matched mapping table
- but without need to alter the user interface significantly - new or
changed features, if any, being the exception.

- And, of course, the whole thing is 'optional' as Ecartis as-is doesn't
need it to function - nor would it in any interim state.

ENDIF

Does anyone (else) see any merit to this?

Might there be enough of a reduction in configuration errors to justify it?


Bill Hacker



[prev in list] [next in list] [prev in thread] [next in thread]