Subject Re: [IB-Architect] IB Aliasing system
Author Olivier Mascia

I should definitely learn how to read the archives ! :-)
Sorry for having repeated what in essence had already been said.

Olivier Mascia, om@..., Senior Software Engineer
T.I.P. Group S.A.,, Director

- ----- Original Message -----
From: "Leyne, Sean" <InterbaseArchitecture@...>
To: <>
Sent: Thursday, November 30, 2000 4:28 PM
Subject: RE: [IB-Architect] IB Aliasing system

> 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:
> 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:
> To unsubscribe from this group, send an email to:
Version: PGP Personal Privacy 6.5.8