firebird-architect - Re: [IB-Architect] IB Aliasing system

Subject	Re: [IB-Architect] IB Aliasing system
Author	Olivier Mascia
Post date	2000-11-30T15:41:24Z

-----BEGIN PGP SIGNED MESSAGE-----

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., www.tipgroup.com, Director

- ----- Original Message -----
From: "Leyne, Sean" <InterbaseArchitecture@...>
To: <IB-Architect@egroups.com>
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: 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
>
>
>
> To unsubscribe from this group, send an email to:
> IB-Architect-unsubscribe@onelist.com
>
>