At 05:22 PM 5/1/00 -0700, Bill Karwin wrote:

>> Is there a good reason to introduce XML?
>
>It'll make it easier to introduce more configuration sections in the future,
>as the community adds more features to InterBase.
>
>For instance, if I want to add a client-access ACL (like Apache's
>allow/deny) feature, I'd write code in the listener to read properties from
>a section that I'd call <AllowHosts></AllowHosts>. In that section are
>several parameters, some are mandatory, some are optional. Some have
>arguments, some don't.
>

This raises a fairly broad question of whether configuration information
is stored in the database itself, presumably in proper tabular form,
or whether it is stored else where. The argument has been made
that the name/file mapping is outside of this question for obvious
reasons, but a principled argument was made that this could/should
be an Interbase database.

I my opinion (ever humble) configuration information internal to
a database should reside in the database. I don't think even the
most die hard XML or Unix fanatic would argue that database meta
data should reside in an XML file or in /etc or as a flat file
in /home/something/somethingelse/interbase/config. Move from a
simple name/filename pair delimited by white space and terminated
with an EOL to something like XML and we create an attractive
nuisance.

Take for example the authentication configuration. I happen to
favor an Apache style module interface with a configuration
blob stashed somewhere in the system tables. It could be
argued that this belongs in the grander Interbase configuration
file. But nothing there is accessible to gbak and is shed
on restoration to a different file name. Or when a name is
innocently reused, it inherits the characteristics of a long
forgotten ancestor.

Lets try to separate managing the name space from other configuration
issue.

And isn't XML to hold of list of name/file pairs a bit of overkill?

Jim Starkey