> I my opinion (ever humble) configuration information internal to
> a database should reside in the database.

Nobody is suggesting that we store truly internal database information like
metadata or SQL privileges or whatever in a text config file. I'm all for
using the RDB$ system tables for most information related to a specific
database.

You were the one who commented a few days ago that there are items of
information that are appropriately stored outside a GDB because one
shouldn't have to attach to a GDB to get them. I think you were speaking
about user/password authentication at the time.

> 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.

This is only exacerbated if the data is stored in a GDB table or in the
Windows registry. Requiring SQL or regedit.exe to read or modify the config
data is unacceptable to most users.

Regardless of the storage format, it'll be a nuisance to modify config
entries if there are inadequate front-end tools to access the config
repository. One could provide a variety of tools, in adition to permitting
direct text editing on the file.

Even Samba has a nifty web interface for config editing, and it uses the
same config file as you would for direct text editing.

Also, an internal API is needed so that developers working inside the
InterBase server code have a convenient way of fetching config entries.

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

Certainly! But name/file pairs aren't the only thing to store in the config
file. Perhaps an alias-specific ACL would be appropriate. I think it's
reasonable to store this information outside the database. I don't want to
connect to the database to find out if I'm permitted to connect to the
database. <g>

Another thing is to provide a structure for future enhancement. Such as a
priority weighting for a given Alias, or alternate mirrored connect strings
so ibserver could be used as a rudimentary load-balancer. The list goes on.

The point is that XML permits an extensible structure for config
information, and at the same time conforms to a well-known standard format.
...and it adds "XML" to the buzzword list for InterBase. :-)

> [concern about integrity]

There's already isc_config data that the server uses, such as the
TMP_DIRECTORY parameter. This is inocuous because it's a read-only server
configuration property.

The unbreakable rule for the config file should be that it is read-only by
the server. The server reads the config into a cache on startup and doesn't
have to touch it again. Internal ibserver code would ask for a property by
name and the config management module would return the value of that
property from a configuration cache.

Actually, perhaps the server should check the timestamp of the config file
and refresh its cache as necessary. For instance, anytime a call to the
"find element by name" method is called, it performs a quick stat() call to
the config file. This allows someone to add a database alias (for example)
at runtime and have it take effect the next time someone tries to connect,
rather than requiring server shutdown to re-read the config.

But regardless, there shouldn't be any data in the config file that the
server writes. Only users (and front-end tools) would write to the config
file.

> [concern about layering and duplication of Y-valve functionality]

I would think the top of the Y-valve is exactly the place that would use the
alias-to-pathname mapping. So there's no breaking of the layer there.

I agree that there's no need to store secondary database files in the config
repository. This information is stored in the gdb file and should be
transparent.

> ...on Windows it is unavoidable to put the a pointer to that
> file (the installation directory) in the registry.

Agreed. InterBase on Windows already uses the registry to store the
InterBase root directory and the location of isc4.gdb. No problem.

Bill Karwin