The dust is beginning to settle. I've got the core plumbing and engine
working in 64 bit mode on Solaris 8 with the Forte compiler, and the
time has come to put the configuration system into action. In these
example, I've used "vulcan" instead of "firebird" to avoid name
conflicts during development. The final names are subject to change,
without or without notice.

The configuration files starts by looking a configuration file in these
places and this order:

1. The value of the environmental value 'VULCAN'
2. A file "vulcan.conf" in the current working directory
3. A file ".vulcan.conf" in the user's login directory
4. A file "client.conf" in the installation directory (from registry
or /opt/firebird)

The server process will always pass a configuration file by setting an
internal environment variable. The server configuration file can be set
by a startup switch. The default is the file "server.conf" in the
installation directory.

My rudimentary "client.conf" looks like this:

#
# This is the generic client configuration file.
#
<database *:*>
filename $0
provider remote
</database>

<database *>
filename localhost:$0
provider remote engine8
</database>

include $(root)/vulcan.conf

Note that it appends "localhost:" to local databases and sends them off
to the remote interface to handle. The remote interface, in turn, gets
out of the business of deciding by ESP who gets local and who goes
remote. Note: the notation "$0" means the entire database name string
that matched the "object" name. $1 means the first wildcarded section,
$2 the second, etc.

The server.conf file is even simpler. The default version, before users
get at it, is:

#
# This is the generic server configuration.
#

include $(root)/vulcan.conf

The root configuration file, distributed by firebird but in fact
tweakable is:

#
# This is the root configuration file. PLEASE DO NOT EDIT
#
<database security.fdb>
filename $(root)/security.fdb
provider engine8 services
</database>

<database *>
filename $0
provider remote engine8 services
</database>

<provider engine8>
library $(root)/lib/engine8
</provider>

<provider remote>
library $(root)/lib/remote
</provider>

<provider services>
library $(root)/lib/services
</provider>

Any finally, the local "vulcan.conf" that I use for debugging:

<database yachts.lnk>
provider engine8
filename $0
</database>

<database security.fdb>
provider engine8
filename $(root)/security.fdb
</database>

<provider engine8>
library c:\firebird\vulcan\src\jrd\engine8
</provider>

include $(install)/client.conf

All this means is that two specific databases, yachts.lnk and
security.fdb, are to be handled by a private engine. Everything else
will go through the normal path through the remote interface to the
server, which, of course, knows nothing of my private configuration file.

It should go without saying that unless I can open a database in my own
process, overriding the local security database gets me nothing, and if
I have write access to the file, nothing could stop me anyway.

Any and all existing firebird configuration parameters can be specified
in a database object, a provider object, or globally. If a system
administrator wished, he could just include "firebird.conf" to inherit
FB 1.5 configuration information.

The code is checked into Vulcan.

I haven't given much thought to other object types. Udf clusters,
security policies, and temp file management all seem to be likely
candidates.


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