Re: Ini File vs Registry
"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message
news:tf5fd4tesg7cu7h2o0dv7spogi23hulkkp@4ax.com...
Well, there is one issue: XML is an all-or-nothing most of the time; it is
nearly
impossible to "incrementally" update an XML file. So if you change one
value, the
question is when do you write out the XML file? For transparency, you
want to write it
immediately; for performance, you want to write it only after the updates
have completed.
When various parts of the program "own" various pieces of the retained
state, this can be
impossible to manage. For component A of your app to reliably update its
part, it can't
be concerned with how component B manages its space. Then there are
issues of thread
safety in updates, if orthogonal components are managing state. Component
A running in
the main GUI thread wants to update the XML file at the same time as
Component B.2, the
second thread running in Component B. There is no conflict if the
Registry is used, but
there is a conflict if you are writing an XML file. You also can get
deadlock in these
situations. I'd rather see an abstract Registry API with application
hives than have to
roll each case out individually.
Also, what happens if Component A opens the file, screws up, and closes
the file which is
now empty. Component B's settings are lost, along with everything else.
When you are
dealing with this in a File>Save situation, you can usually do something
sane, but with
distirbuted state-saving calls throughout the interface, you can't have
one component
losing the entire ball of wax because it failed in some odd way.
It also means there is a fair amount of complexity to deal with the state
you *don't*
handle (I know, I've done this; in fact, our original LG system in 1977
addressed exactly
this issue, of transparent pass-through of data a component couldn't
handle. It's not as
easy as it first appears, and we eliminated this feature in the IDL system
and replaced it
with a multiple-inheritance model, which introduced yet a different set of
problems)
I don't understand. Your CWinApp derived class contains the XML parser
instance and it contains an in-memory image of the current document's DOM.
Any component accesses methods of the parser to update the DOM. When it's
done, it calls the Write() method to save the DOM to the disk. This would
need to be protected with a critical section for thread safety as you noted
(it is not required in my apps since all user settings are written in the
GUI thread). If there is a disk error, backup xml files or some other
scheme could be used. It is not more fragile than registry write failure.
Sure, writing XML is all or nothing, but since the XML file is so short, it
doesn't matter.
In a well-designed system, I could create a database in three lines of
code plus a schema
table, write accessors for the records, and record fields in a set of
tables that were
easily defined. In the past, I did this, but Microsoft has made databases
so complex that
you can't just toss one at the application without going through a massive
learning curve.
Compare, for example, the old Paradox library with the OLEDB library.
Significant
complexity differences. We did an app in 1996 that stored all of its
state in Pardox
databases, because Win16 had a very limited Registry. I learned the
library in a day.
Given a choice, I'd use a database, but I'm not given that as a practical
choice.
You are right the registry is a very robust, transacted, hierarchnical
database, but for most purposes of saving a few settings, that doesn't
matter. In fact, as I said, registry fragmentation caused very poor
performance linked to my app, when in fact my app was not responsible at
all. So the registry is not necessarily the all-powerful be-all-and-end-all
location to save things by default. I also disklike that even though it has
a current user hive, my app's settings are mixed with yours. This is a
phenominally bad approach.
-- David