Rock on, Bill.

This is an awesome idea. How do you propose to get the address of the
list server to the application without coding it? Maybe (God, please don
strike me dead for suggesting this) we need some sort of broadcast
protocol. Can a DHCP server be set up to hand out a specific LDAP server
address to each client?

Something like SMB or DHCP would be needed to make such a system as
awesome as it sounds. Maybe a version of something like WINS (which is
basically a router for SMB over TCP). That way, neither the support
people nor the users would need to know what DB/Server to config the INI
for or specify in the registry, and/or developers would no longer need
to hard code an ODBC connection or a server/DB setup in their app.

The only thing better than this is a web app. Web apps are (in my humble
estimation) the death of locally installed client/server apps. Even with
a web app, though, you have to set up the connection to the DB.

I come from a large PC support group at 3M. We supported about 30
different in-house client/server apps. PowerBuilder, VB, intranet, etc.,
for about 25-30 thousand users in the Minneapolis/ST. Paul, MN area. I
had to remember the ODBC DSN, Lotus Notes (used ODBC to read/write
Sybase tables) server name for the ini, whatever, for each group for
each app (alot of them were shared, especially the manufacturing apps in
PowerBuilder). On top of that, some apps used Sybase, some Allbase, and
some SQL. Some used a local Access file (either c:\whatever or
\\server\share\whatever).

This is awesome. My head is kind of spinning. We could allow the
creation of "domains" so that users from the HR unit get connected to
their DB, while the users from Sales get connected to their DB. It could
be interfaced with NT security. I suppose it would be Dynamic
ODBC(-like) Server. It could even tell a VB app to use an Access .mdb
file from the appropriate location. No more hard coded DB connection,
either native or ODBC.

How can I help? My C is really lacking, but I'd luv to learn, expecially
for a project like this. My stronger skills would lie in the conceptual
development area... i.e. what does it do, how does it do it, what are
it's parts, etc.

Lemme know! I'm serious.

Jared
Bill Karwin wrote:

>
> Dmitry Kuzmenko wrote:
> > I do not understand why LDAP idea rised at all.
> > LDAP and other tools only useful to know what public resources are available.
> > (maybe for more tasks, but it's not sufficent).
>
> That sounds perfect for describing databases on a LAN that are available
> to a client application! Databases are effectively "public resources",
> from the application's point of view, right?
>
> I suggested LDAP simply because it's an open standard. Administrators
> generally know how to change an object in an LDAP directory. There are
> nice GUI tools to do this.
>
> > Database server is not the same. Nobody except application developer
> > need to know how databases on the server are named, in what directory
> > they are placed, and moreover, what alias need to be used to access
> > these databases.
>
> The application needs to know. When a user runs the app, it needs to
> know how to connect to the database. Currently, that's hardcoded in the
> app or else the BDE driver looks it up if you use BDE. What I'm
> proposing is to do an alias lookup in the gds32.dll just like BDE does
> for its aliases now--except InterBase aliases could be stored locally or
> else on a central server.
>
> > aliases for IB is only needed to hide full database paths and names.
> > Don't they? So, this does not mean that alias list must be published
> > in any way.
>
> I was hoping to extend this alias concept to hide server names as well
> as pathnames. That means that the client must do the lookup. But it
> can be done transparently--the user never needs to know the location to
> which the alias maps.
>
> > If some administrator wants to create published DB alias list, he can
> > do it right now using sockets or other tools (maybe MIDAS).
>
> MIDAS is a proprietary, Windows-only solution. Inventing a new
> mechanism from scratch is unnecessary.
>
> > Application first will connect to alias server, then take alias,
> > server, database path and name, and then connect to database.
>
> Exactly right. The application (client) connects to a server to query
> the alias name, and retrieves a traditional InterBase connection
> string. Then the application proceeds to connect over a network to the
> IB server.
>
> What we're discussing is whether we implement this using an existing
> open standard for a remote directory repository, or we reinvent the
> wheel again.
>
> > Why client gds32.dll need to know where alias maps and even real database name???
> > I thought that database name only used to say SERVER what database must
> > be open for client. So, client is not interested how database is named.
>
> I agree fully. The user doesn't care where the database is located, so
> he wants to connect to a simple name like, "PersonnelDatabase". In
> order to abstract the server name as well as the path of the database on
> that server, we need to allow the client software to look up the alias
> from some other information repository. This is the same concept as
> DNS.
>
> The advantage is that the application knows only the name
> "PersonnelDatabase", and the location of that database can be moved from
> server1 to server2 simply by the administrator changing the central
> alias definition. We shouldn't need to update the clients to know
> "server2:PersonnelDatabase".
>
> > Have you seen applications that can work with different databases, and
> > they are not development tools? database names are almost hard-coded
> > in applications.
>
> Why limit ourselves to what other applications do? :-)
>
> Bill Karwin
>
>
>
> To unsubscribe from this group, send an email to:
> IB-Architect-unsubscribe@onelist.com