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

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

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

Other quick proposal.

(o) Add a new service to the services API with functions to list, add, remove an alias. Let's do it so that *only* SYSDBA can add/remove an alias. Others can only query and retrive the alias string itself (and not the associated local path and db name).

(o) Update the parsing of connections strings on the server. If what is considered today to be the 'local path' part of connection string starts with a ~ (tilde, much like virtual paths on most webservers) assume what follows the ~ to be an alias string. Server matches it against its alias list, and access the db or fails connection if the alias is not found.

(o) Per design, from day one, make the alias strings to be totally non case sensitive and only valid if consisting of characters a-z, A-Z, 0-9, . (dot) and _ (underscore) : much like internet domain names.

(o) Get rid of those local, client-side oriented, aliases in IBConsole and similar tools. Just add access to the new Service API to allow SYSDBA to define/drop new aliases.

I do not define in this proposal how those aliases should be stored. It does not matter. Inside ISC4.GDB would be fine, but inside a plain text file in the installation root (where isc4.gdb stands) is also perfect.

Example of 'aliases' file :
Mydb, /usr/home/databases/mynice.gdb
LEDGER.ERP, C:/usr/local/db/ledger.gdb

Example of connection string :
localhost:~ledger.erp
dataserver:~mydb
localhost:C:/data/test.gdb (this one does not use aliases)

So you keep all the semantic available today. You can still reference a full path in a connection string, you break nothing, EXCEPT OF COURSE and maybe full path which would happen to start with ~ (I guess we can accept this).

Am I wrong ?

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

- ----- Original Message -----
From: "Marcelo Lopez Ruiz" <marcelo.lopezruiz@...>
To: <IB-Architect@egroups.com>
Sent: Thursday, November 30, 2000 4:08 PM
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
>
>