At 11:04 AM 5/2/00 -0400, Doug Chamberlin wrote:

>
>I don't think we are talking about just a simple list, unless you mean a
>separate file for each database. How about:
>
><?XML version="1.0" standalone="no"?>
><!DOCTYPE ISCNS:FileMap SYSTEM "http://xml.interbase.com/FileMap.dtd'>
><ISCNS:FileMap xmtns:ISCNS='http://xml.interbase.com/'>
><Database>
> <Alias>MyDB</Alias>
> <File>C:\Data\DB01.GDB</File>
> <File>C:\Data\DB02.GDB</File>
></Database>
><Database>
> <Alias>MyOtherDB</Alias>
> <File>D:\OtherDB.GDB</File>
></Database>
></FileMap>
>
>

Other than breaking the layer and destroying database integrity,
this isn't a bad idea.

First, the layering. It is the Y-valve that establishes a
connection to a database subsystem. Name translations must
either reside in the Y-valve (good) or be replicated in each
of the subsystems (bad). The database engine operates off
the root database file which identifies other files (additional
page segments, shadow files, etc). Your model would require
that the engine read and write the configuration file to
keep track of the files. This requires that the engine
also access the configuration file. Does it make sense
to have two layers fighting each other?

The integrity issue is fundamental, and brings a light to
the whole Unix philosophy of ascii configuration files
modified by text editors. There is no concurrency control.
Under your model, the engine must not only read the configuration
file but write it also to reflect additional file, shadows,
etc. If the engine were to write the file while somebody
else had it his editor pending update, the config file update
would be lost. Or, if a file level lock used, the engine
would be blocked pending access to the file. Neither is
very appealing.

Someday the Unix guys will figure out that multi-application
servers require something more robust that text configuration
files (probably sometime after they discover that only marked
entrypoints should be visible in a shared library). Then
they will have to invent something in the same ecological
niche as the VMS Common Data Dictionary and the Windows
registry. It's part of growing up and we should be patient.

I don't object to a flat file to hold database name mappings.
But on Windows it is unavoidable to put the a pointer to that
file (the installation directory) in the registry. Sorry, but
that's the way Windows works.

How about:

MyDB C:\Data\DB01.GDB
MyOtherDB D:\OtherDB.GDB
<end-of-file>


Jim Starkey