Jim, you seem to feel strongly about this issue, and I welcome your wisdom.
The idea to make the config file a flat file with XML formatting is just a
proposal. If you have an alternate proposal, I'm all ears (or eyes, in this
medium).

Still, for the sake of constructive discussion, I'll try to respond to your
points.

From: "Jim Starkey" <jas@...>

> there are likely to be both development and production groups
> using different generations of a UDF library. A unified, system
> wide configuration file would make this impossible.

What did you think of the architecture that I described the other day, in
which functions could be declared globally in the config file, or they could
be omitted from the config file and declared individually in each database
as in the current InterBase DECLARE EXTERNAL FUNCTION mechanism? That way
you could choose to have certain UDFs declared in the context of a different
database, using a different shared library and entrypoint.

In other words, permit system-wide configuration but also permit overrides
at the per-database level.

> the application vendor would have to
> write and maintain a non-trivial program to update an arbitrary
> configuration file. Given that the config file is essentially
> open ended, this is a problem.

But it is simplified by using a standard format like XML, for which there
are several open-source packages in various languages to read and write.

InterBase 6 introduces an Installation API, which simplifies the process of
writing turnkey installations. This includes an API for entering license
keys, for instance, so that the application vendor can write their own UI
for users to enter keys.

It would be an extension of this facility to create an API for application
vendors to specify configuration parameters. The API would do the proper
things to try to get exclusive access to the config file, modify the
relevant items, and release the lock.

> How do two users (or two programs) simultaneous update a configuration
> file?

Really, how often do you think this will come up? 70%+ of InterBase
installations are on NT, where it is unlikely that two people can work on
the console at the same time, and remote access is very limited. Most shops
won't have more than one person who is even _capable_ of configuring
InterBase (sometimes fewer!). I think some simple file-locking mechanism
would be adequate. If InterBase supplies a convenient API to the config
file, this would make it more likely that tools would all follow the locking
rules. Then one only has to worry about folks who hand-edit the file, but
they are taking the responsibility for integrity when they choose to do
this.

> When does the engine reparse the configuration file?

The suggestion I made earlier was that every time a module in the server
requests a config item from the config cache, the config manager stats the
config file and refreshes the cache if needed. I guess that this interface
therefore has to be re-entrant, and to block requests for config items while
it perorms the refresh. There would be a slight "hiccup" or delay in server
performance shortly after one edits the config file, but it quickly resumes
cached access.

> What does it do if it finds an error in the config file?

I assume it would be adequate to write the offending config entry into the
interbase.log and continue using the prior cached configuration.

Perhaps it would be helpful to add SNPP support to the server to page a
system admin when certain errors (like config syntax errors) are written to
the log file?

Also, hopefully whatever front-end UI provided to edit the config would do
some validation. Perhaps the Config-editing API should do this. Folks who
edit the config file by hand with a text editor are on their own.

> The suggested XML syntax for UDF declaration is horrible. Function
> declarations should look like function declarations, not a debased
> web page. Why should we want to inflict this gook on our users?

It's a question of taste, obviously. The syntax is functionally equivalent.
One could say the same curmudgeonly things about function declaration
syntax. Anyway, it's unlikely that most users would ever see the syntax
regardless of its form, because they would access the config through a GUI
or web interface.

> I don't want to go back to the model where
> everything has to go through system managers.
> XML in this context is a solution looking for a problem.

Fair enough.

> I am not convinced that the isc4.gdb model of a single list
> of users/passwords is a good idea. What if two projects
> are totally disjoint, with different user communities?
> What if a user wants different passwords in different
> applications?

Right, we've seen this request periodically on the InterBase list. For
instance, I recently read a question from a fellow who wanted SYSDBA to have
different passwords to access different databases.

> Microsoft's IIS requires that every web
> login account have a domain account. This drives organizations
> straight to Linux and Apache, which allows any number of
> authentication lists. Do we want to assume the role of
> Microsoft?

The converse is also true in some situations, where IT staff tires of
maintaining N different authentication lists, and tries to unify them. The
problem is complex to solve in a flexible way, because there are so many
different requirements.

I think the best solution is the one we've been discussing regarding plug-in
authentication modules. The extra wrinkle is that InterBase would have to
support _multiple_ concurrent authentication modules, so that one database
could authenticate using a local flat passwd file, and another database on
the same server could authenticate users according to an NDS server or
whatever.

> I would like the first authentication plug-in be support for isc4.gdb
> ...we can back away from it in favor of Apache style authentication lists.

You mean for each given database Alias, declare a potentially different
authentication repository? Sounds great.

This, by the way, is a perfect example of the config repository (whether it
be flat file or database) containing more data associated with an Alias than
simply the filename mapping.

Regards,
Bill Karwin