Here is what I think we should do:

1. A configuration file follows Apache meta-syntax: an object
represented by object type and object name in angle brackets,
followed by attributes and associated values, one per line,
terminated by the slash-object type in angle brackets.
2. Objects can be overloaded by name and by wildcard. When searching
for an object by name, the first hit wins.
3. The primary objects are <database> and <server>. I'm sure we'll
think of more.
4. A configuration file can (usually will) terminate with an include
of another configuration file. A user configuration file will
link to a group configuration file which links to a project
configuration file which links to a system configuration file
which links to a (non enforceable) sacrosanct Firebird
configuration file. All of this is convention and can be replaced
in toto by the creative.
5. A configuration file is found by an established search list
starting with an environmental variable.
6. A named database object can have a database file name, a remote
connection string, optionally a server object name, and other good
and valuable considerations.
7. A named server object can identify a connection mechanism, port,
ipc handshake, or indicate the engine is to run in-process (aka
embedded, classic, etc.).
8. A server is started with the named of a configuration file. If
the file isn't in a reasonable secure location, somebody screwed up.
9. A user can override anything in his configuration file to his
hearts content. The server is never going to see it.
10. There is no definitive configuration file, but a cooperative bevy
on configuration files managed by folks of varying authority and
responsibility.

The product ships with a fixed Firebird configuration file with wild
cards for server and database name with intelligent defaults. A system
manager can set up another configuration file linked to the Firebird
file overriding anything he or she sees fit. The project manager can
override but link to the system file, the group file to the application
file, and the personal configuration to group file. None of these has
to exist unless somebody wants it.

A user (or group) can use a temporary configuration file to redirect a
named database to a debugging version. When they delete the file (or
change its contents), control reverts to the next matching database name
or wild cards up the food chain.

There is no Y-valve configuration, per se. A database can name a server
object for in-process usage. There is no guarantee from the
configuration mechanism that the user will actually be able to open the
database file for in-process use. If he or she tries a quick one,
system file security will block the attempt.

I'll crank out an example tomorrow. But the key ideas are cascading
files, named objects overload, inheritance of policy with the ability
for local overrides. Firebird manages what no one else does. Who does
what is up to the user organization. The individual is in control
within the hard constraints established by the powers that be.


[Non-text portions of this message have been removed]