Re: [GD-General] A portable preferences library

[Colin F. <cp...@ea...>]

2003 December 4th
Thursday

I have used the following scheme for storing user preferences for
an application:

[1] A plain text file in the same directory as the executable,
       with the extension *.txt rather than something else (like
       *.ini);

[2] The application, when launched, can determine the path of its
      executable file, and thus the location of the corresponding
      user preferences text file;

[3] All aspects of reading the user preferences text file are 
      fault-tolerant; re-ordering, adding, removing fields will
      have the least possible effect -- and field values are 
      similarly checked and clipped to sane limits.

Security of the preferences is not an issue for my use of this
scheme.

Benefits of this scheme:

  [a] One can have many independent instances of the application
        on a single machine, each with different preferences;

  [b] The user can edit preferences if the application malfunctions,
        which is impossible in a scheme where the application itself
        is the only entity that can manipulate the preferences file;

  [c] Users can send or receive preferences files, or disucss
        specific named settings, via e-mail or web pages;

  [d] Settings in the preferences file can correspond to an
        application's scripting system -- so that the preferences
        file is nothing more than a batch of scripting commands
        that can otherwise be entered at run-time in the 
        application itself (as in a console window for a video
        game);

  [e] Settings persist after clean install of operating system;

  [f] Application and settings can be stored on a CD-ROM or
        portable disk or flash-memory device, and one can 
        take it to someone else's computer and operate the 
        application without doing an "installation" or 
        polluting their computer with any files whatsoever;
        (I bring my prototype applications to a friend's house
        for demonstration on my keychain USB memory device,
        and execute directly from the keychain!)

Basically, I'm a strong believer of the settings following the
application around.  I think the old MacIntosh operating system
hid a kind of directory system behind the application icon --
with the "resource fork" and "data fork", which was a pretty
good idea because it allowed data associated with a program to
be bound to the program.  Thus, moving or copying the icon
would assure that all settings and data moved with it.
It was a nice abstraction that simplified the notion of 
"application" and reduced confusion when moving it around.

Maybe I'm hard-core, but I think everything an application needs
to operate, short of the absolutely guaranteed resources of the
operating system, should be packaged with the application --
and totally portable.  I should be able to run any application
on anyone's computer from my keychain memory device, without
adding any files to their computer!

I think multi-user systems is an antiquated concept.  But if
I must support multiple users of a single application (as opposed
to each user installing his or her own copy of the application),
then individual preferences files can be stored with the application.
"preferences_bob.txt", "preferences_joe.txt", etc.  Putting these
preferences anywhere else but with the application leads to 
potential pollution that might never go away.  Lots of irresponsible
developers don't do a good job of un-installation -- or somehow the
application disappears from the computer without un-install ever
happening, leaving tons of scattered junk behind.

I always thought the Windows registry was a disaster; it encouraged
people to centralize critical information, and it has been a source
of confusion and annoyance for users.  Protecting the integrity of
this single trash heap is silly.

Okay, I sympathize with the idea that putting everything in one place
somehow seems more organized.  I dislike the idea of things being
scattered around.  But I think it's perfectly good to put things in
self-contained bundles that do not rely on any centralized thing or
on scattered things.  It's very clean.

I think rather than pushing itself upon one's computer (like a formal
installation procedure), applications should be passive and the 
operating system should instead scan for applications upon boot-up.
Thus, the "Start" menu is populated at boot time and is 100% in
sync with available applications.  Applications can contain 
preferences about placement in the "Start" menu hierarchy, much
like an application can propose its own icon.  The key is to eliminate
the idea of "installation".

Okay, some of these ideas are radical, but I just wanted to share my
own thoughts about preferences files.

--- Colin

cp...@ea...