I've added a wrinkle to allow multiple translations/rewriting of
database names, as in:

<database employee.lnk>
filename yachts.fdb
</database>

<database employee.fdb>
filename $(install)/examples/employee.fdb
</database>

include $(root)/vulcan.conf

where $(root)/client.conf contained

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

So a database string of "employee.lnk" would be translated, in turn to

* "employee.fdb"
* "c:\Program Files\firebird\examples
* "localhost:c:\Program Files\firebird\examples

before being sent off to the provider "remote".

There are, of course, rules:

1. Translation stops on the first database object that contains a
"provider" attribute
2. Translation stops on a detected cycle
3. Translation stops after a fixed number of iterations, currently an
arbitrary 10.

I've toyed with the idea of chaining the configuration objects for
intermediate translations to the final privider for attribute
translation, and have rejected the idea. While it might be nice to have
a database object give a port number for a subsequent remote provider, I
think it better that the database object containing the provider has a
local monopoly on specifying attributes for that provider. The
configuration object implementation does provide for an arbitrary
chaining of configuration objects, so this decision could be changed
with a couple of lines of code if someone where to make a convincing
argument to the contrary.




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