[Tfug] Stored settings

[Bexley Hall]

Hi, Jim,

> >> >So, are there any other reasons why you might opt for the
> >> >"easy way out" (non-human-readable forms)?
> >> 
> >> Only the ever-popular LP (Lazy Programmer) Syndrome.
> >
> >Well, it can also be argued (?) that it is more robust
> >(in that the range of legal values is more tightly
> >constrained as in your comment below).
> >
> >OTOH, one could argue that a "textual" representation tends
> >to have a larger Hamming distance and, in theory, easier to
> >recover from database corruption  :-/
> >
> >(though I sure as hell wouldn't want to be writing the
> >code that makes those judgement calls!)
> >
> >> I agree - these days there is no reason for info or config
> >> files to be in a
> >> machine-readable-only form.  Of course, using "3"
> >> in your example instead
> >> of "Never" simplifies things so that the
> >> programmer doesn't have to look
> >> for "Never" "never" "NEVER"
> >> "N3ver" "NotInMyLifetime" etc.
> >
> >strcmp(tolower(value),  TOLOWER("Never"))
> 
> Somehow I knew you'd say that.  That's why I threw
> in "N3ver".

I think an implementation has to *prevent* "bad data" from
getting into the configuration in the first place.  E.g., if
you let everything be flat ASCII files that a user can manipulate
with {vi,ed,qedx,emacs,etc.}, then he/she can create an "invalid"
file (if you assume any invalid entry invalidates the file itself).
E.g., "N3ver".

OTOH, if you put a gatekeeper between the user and the file,
you can catch any "bad data" before it gets into the file.
Thereafter, any "bad data" that the application encounters
can be attributed to a failure in the "filesystem" (or whatever
mechanism stroes/retrieves this configuration data).  As such,
you can apply whatever corrective means seem appropriate given the
failure characteristics of that mechanism.

> Your point about using this to look for a corrupted file is
> an interesting
> take on things.  I typically put some long text string in
> various places in
> files that I want to check automatically for corruption at
> an idiot level.

I check signatures at load time and at run time.  (note that I
typically don't have the luxury of telling the user "please reboot")
 
> But on the core issue, I think human-readable in config and
> info files is a
> must.  I went with XML for a while (a SHORT while) for
> these types of files
> until I realized that it failed the human-readable (with vi
> or notepad)
> test big-time (the realization coming when I revisited some
> old XML config
> files and could not figure out what they meant without
> RTFM).

Exactly.  And, in my case, I'm dealing with appliances... the user
doesn't want to sit down to browse some complex document just to
figure out how the address book is sorted in his cell phone...  :-/
Given the size of those freaking tiny screens...  :-(

Thx,
--don