Configuration File

From Jim Starkey on the Firebird Development List 4th Jan 2003

Here is what I think we should do:

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.

Objects can be overloaded by name and by wildcard. When searching for an object by name, the first hit wins. The primary objects are and . I'm sure we'll think of more.

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.

A configuration file is found by an established search list starting with an environmental variable.

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.

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.). A server is started with the named of a configuration file. If the file isn't in a reasonable secure location, somebody screwed up.

A user can override anything in his configuration file to his hearts content. The server is never going to see it.

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.