Dmitry Kuzmenko wrote:

> I do not understand why LDAP idea rised at all.
> LDAP and other tools only useful to know what public resources are available.
> (maybe for more tasks, but it's not sufficent).

That sounds perfect for describing databases on a LAN that are available
to a client application! Databases are effectively "public resources",
from the application's point of view, right?

I suggested LDAP simply because it's an open standard. Administrators
generally know how to change an object in an LDAP directory. There are
nice GUI tools to do this.

> Database server is not the same. Nobody except application developer
> need to know how databases on the server are named, in what directory
> they are placed, and moreover, what alias need to be used to access
> these databases.

The application needs to know. When a user runs the app, it needs to
know how to connect to the database. Currently, that's hardcoded in the
app or else the BDE driver looks it up if you use BDE. What I'm
proposing is to do an alias lookup in the gds32.dll just like BDE does
for its aliases now--except InterBase aliases could be stored locally or
else on a central server.

> aliases for IB is only needed to hide full database paths and names.
> Don't they? So, this does not mean that alias list must be published
> in any way.

I was hoping to extend this alias concept to hide server names as well
as pathnames. That means that the client must do the lookup. But it
can be done transparently--the user never needs to know the location to
which the alias maps.

> If some administrator wants to create published DB alias list, he can
> do it right now using sockets or other tools (maybe MIDAS).

MIDAS is a proprietary, Windows-only solution. Inventing a new
mechanism from scratch is unnecessary.

> Application first will connect to alias server, then take alias,
> server, database path and name, and then connect to database.

Exactly right. The application (client) connects to a server to query
the alias name, and retrieves a traditional InterBase connection
string. Then the application proceeds to connect over a network to the
IB server.

What we're discussing is whether we implement this using an existing
open standard for a remote directory repository, or we reinvent the
wheel again.

> Why client gds32.dll need to know where alias maps and even real database name???
> I thought that database name only used to say SERVER what database must
> be open for client. So, client is not interested how database is named.

I agree fully. The user doesn't care where the database is located, so
he wants to connect to a simple name like, "PersonnelDatabase". In
order to abstract the server name as well as the path of the database on
that server, we need to allow the client software to look up the alias
from some other information repository. This is the same concept as
DNS.

The advantage is that the application knows only the name
"PersonnelDatabase", and the location of that database can be moved from
server1 to server2 simply by the administrator changing the central
alias definition. We shouldn't need to update the clients to know
"server2:PersonnelDatabase".

> Have you seen applications that can work with different databases, and
> they are not development tools? database names are almost hard-coded
> in applications.

Why limit ourselves to what other applications do? :-)

Bill Karwin