[Tfug] Stored settings

Robert Hunter hunter at tfug.org
Tue Dec 9 16:52:22 MST 2008


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

>> Minimally, you should have a formal specification of the data
>> format, and, ideally, a robust set of tools for performing IO,
>> validating, and transforming your data.

On Tue, Dec 09, 2008 at 12:54:48PM -0800, Bexley Hall wrote:

> Exactly!  That is the point of the question.  If I bundle ALL of
> these issues together in the interface *to* the "config database",
> then I achieve all of the goals in a manner that is maintainable
> and far more usable (to the end user) than the traditional approach
> of keeping them all as separate -- though logically linked --
> entities.

You, more than anyone else, should know what is "the right thing
to do".  But since your question was phrased in general terms, my
answer was, too.

> I.e., having a specification is only meaningful if the user has
> access to it, if it is written in a form the user can easily
> parse, *and* if it is kept in lock-step with the actual implementation!
> If any of these get out of sync, then they are worse than useless
> as they will only ADD to the user's confusion.

Once again, it is for you to decide what is best for yourself, so
don't take this the wrong way.  But I maintain that any software that
is destined for release should be documented in exacting detail,
particularly the data that it accepts, and the data it produces.  Yes,
this requires significant effort.  Yes, software updates may require
documentation updates. Yes, failure to do so may be thoroughly
misleading, and elicit a steady stream of bug reports and death
threats.  Oh, well -- now you're in the big leagues!

Allow me clarify my point in relation to your original post: Other
than aesthetics, I don't think it matters if you say...

"EraseBootDriveOnPowerUp = Never"

or

"EraseBootDriveOnPowerUp = 3"

or

"ButterScotchCookies = HidyHo"

or even

"ConfigurationOption612365 = 24.32.16.hike.hike.hike"


...so long as somewhere there is something written to the effect of:

EraseBootDriveOnPowerUp: this option will perform an "erase" operation
on the "boot" drive that is reported by the OS using the
PEZIX-compliant frobnitz (2) function.  Valid values for this option
are *foo*, *bar*, and *stickygumboots* These options are further
explained in the following section...


HTH

- --
Rob
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFJPwS2J1pz6tWxufARAnzCAJsEYidUW0t5xatAcz1odIzqNEyaOQCcDd2p
malVQ3+jwWSgFRU8xd06ZLw=
=ll3k
-----END PGP SIGNATURE-----




More information about the tfug mailing list