| Subject | Re: [IB-Architect] Re: Is it _really_ necessary to expose the location of the database file? |
|---|---|
| Author | Olivier Mascia |
| Post date | 2000-08-14T15:56:12Z |
I may have missed some important part of the discussion (though I think I
silently read most of it over the last days), but what benefit is there to
handle client-side aliases, provided that we would have such on the server
side ?
I never liked the concept of client aliases to databases. That's a personal
opinion, for sure. I know ODBC has them. BDE has them. And IBConsole tried
to introduce them (the bad way in my opinion). But is this a sufficient
reason to play with that ?
Aliases on the server-side (handled solely by the server) and stored in
ISC4.GDB (or anywhere else on the server -- but ISC4.GDB sounds good) look
pleasant. You use them if you want, but you don't have to. You can go with a
straight path, if that fits your design.
What should not be left out of the design is some way to browse, add, update
and delete aliases from the client side. Simplest idea : add that
functionnality through the Services API, pretty much the same as it was done
for users. Not all client application will use that (if it was, aliases
would not be usefull at all). But that allows to build administrative client
interfaces.
What's the point or advantage of NOT even needing to know the server name ?
At some point or another, you'll need to know it __anyway__ : to setup the
right alias (at setup time or later). Now, if we want to automagically
discover _the_ server, let's leave that to the application
designer/programmer. I use CORBA Naming Services for that, because it suits
my application. Others may use anything else they like. Including the so
simple solution : provide the client application with a configuration dialog
box, where the user can browse the machines names on the network, select
one, click 'test' to test the connection against that server, and if
successfull, let it store this setting for the next time. Hiding the real
server path in the client application thanks to the alias is a good thing.
Not even have a config screen for just keying in the server name is surely
pushing things a little bit too far. Well, IMHO.
-------------------------- www.tipgroup.com -------------------------
Olivier Mascia T.I.P. Group S.A.
om@... Company Phone +32 65401111
Director, Senior Software Engineer Private Mailbox/FAX +32 43204716
silently read most of it over the last days), but what benefit is there to
handle client-side aliases, provided that we would have such on the server
side ?
I never liked the concept of client aliases to databases. That's a personal
opinion, for sure. I know ODBC has them. BDE has them. And IBConsole tried
to introduce them (the bad way in my opinion). But is this a sufficient
reason to play with that ?
Aliases on the server-side (handled solely by the server) and stored in
ISC4.GDB (or anywhere else on the server -- but ISC4.GDB sounds good) look
pleasant. You use them if you want, but you don't have to. You can go with a
straight path, if that fits your design.
What should not be left out of the design is some way to browse, add, update
and delete aliases from the client side. Simplest idea : add that
functionnality through the Services API, pretty much the same as it was done
for users. Not all client application will use that (if it was, aliases
would not be usefull at all). But that allows to build administrative client
interfaces.
What's the point or advantage of NOT even needing to know the server name ?
At some point or another, you'll need to know it __anyway__ : to setup the
right alias (at setup time or later). Now, if we want to automagically
discover _the_ server, let's leave that to the application
designer/programmer. I use CORBA Naming Services for that, because it suits
my application. Others may use anything else they like. Including the so
simple solution : provide the client application with a configuration dialog
box, where the user can browse the machines names on the network, select
one, click 'test' to test the connection against that server, and if
successfull, let it store this setting for the next time. Hiding the real
server path in the client application thanks to the alias is a good thing.
Not even have a config screen for just keying in the server name is surely
pushing things a little bit too far. Well, IMHO.
-------------------------- www.tipgroup.com -------------------------
Olivier Mascia T.I.P. Group S.A.
om@... Company Phone +32 65401111
Director, Senior Software Engineer Private Mailbox/FAX +32 43204716
----- Original Message -----
From: "Mark Shapiro" <Mark.Shapiro@...>
To: <IB-Architect@egroups.com>
Sent: Monday, August 14, 2000 3:48 PM
Subject: RE: [IB-Architect] Re: Is it _really_ necessary to expose the
location of the database file?
>
> >I suggested making aliases client-side, so that user applications
> >wouldn't even have to know the server name.
> >
> >But if aliases are kept on the server, then you don't need permissions
> >because you can just restrict access to the drive where the InterBase
> >software resides (a good idea anyway).
>
> Why not both? Allow client-side aliases, AND server-side aliases?
>
>
>
> To unsubscribe from this group, send an email to:
> IB-Architect-unsubscribe@onelist.com
>
>