Marcelo,

Good idea, but way too over engineered.

If you have a look at the archives, you'll see that the last idea was to
simply allow for an alias name to be used in the connection string in
place of the usual database specification. The engine would then be
responsible for determining whether the connect string was an alias name
or db string and then act accordingly.

This approach allows for complete backward compatibility.

The discussion did digress when it came to the issue of remote
management and the appropriate storage medium/location for the alias
information. There were suggestions of ISC4.GDB, another GDB file, INI
file (my personal preference), XML file and finally linking to a
directory service (your choice of version/implementation)

The only reason this has not moved forward, is that people are still
working on getting the product build process stable, working on new
product ports, getting familiar with the code (given the abundance of
technical documentation - read: extremely sarcastic) and then looking
into some truly drop dead bugs.

I have no doubt that the alias feature will be implemented in an early
release of the Firebird project.


Sean

Sean

-----Original Message-----
From: Marcelo Lopez Ruiz [mailto:marcelo.lopezruiz@...]
Sent: Thursday, November 30, 2000 10:08 AM
To: IB-Architect@egroups.com
Subject: [IB-Architect] IB Aliasing system

OK, here's my take on an aliasing system.

To connect to a database, client applications hold a simple alias name,
e.g.: OurDatabase, and an "alias resolver" machine name/IP address,
e.g.:
DbResolver.

The client connects to DbResolver on a well-known port, and present the
alias. The DbResolver returns an error message or a standard connection
string, such as dbserver1:c:\ourdatabase.gdb.

Pros:
1. Little impact on client applications: it's just a step to be done
before
connecting; existing stuff keeps working.
2. No changes to existing code base.
3. Very easy to implement on Windows (and I suppose not too difficult to
implenet on *IX).

Cons:
1. An additional port to be opened, an additional program to be setup on
the
server.
2. The address of the resolver has to be hard-coded on the client
(although
this might be saved with a broadcast).

Things I intentionally ignored:
1. Remote administration. There is *no* remote administration.
Administrators can log in at the server computer and modify a text file,
or
use vi/whatever through a telnet session. I'm keeping this simple
2. No security/authentication. Security can (and should!) be implemented
at
the database level. If you don't want your users tampering with the
database
file(s), keep their hands off the filesystem

I'd like other people's input on this before starting to write anything.
What am I missing? What obvious, glaring holes can you see here?

TIA for bearing with me,

Marcelo Lopez Ruiz



To unsubscribe from this group, send an email to:
IB-Architect-unsubscribe@onelist.com