jaredcr wrote:

>
> Rock on, Bill. This is an awesome idea.

Thanks! I'm glad someone likes it. :)

> How do you propose to get the address of the
> list server to the application without coding it?

Thankfully a broadcast protocol isn't necessary, as long as the host
running the LDAP service is known.

It's a similar model to DNS: if the DNS server resolves hostnames to IP
addresses, how do you know where the DNS server is? You have to specify
the IP address of the DNS server in your network configuration. It's
got to start somewhere... :)

Likewise, the IB client needs to know at least the location of an LDAP
repository in order to access it. We also are discussing putting
aliases in the ibconfig file, so why not use that for the LDAP server?

For example, in Netscape Address Book, you can use LDAP:
- File->New Directory...
- Specify the LDAP server hostname
- Specify the Search Root, which is sort of like a WHERE clause in SQL,
to restrict the result set to a subset of values.
LDAP is extensible, and we can design a schema for InterBase database
aliases.

> 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).

LDAP specifies a protocol that runs on top of TCP/IP. It's part of the
standard.

> 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.

Web apps can be considered clients like any other. They use the IB
client library to connect to the database, so they can use aliases too.

Let me think about your other comments for establishing domains of
databases. It's interesting, if a bit beyond the scope of what I was
proposing.

Bill Karwin