At 01:27 PM 5/3/00 -0700, Bill Karwin wrote:

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

Yeah, I guess I do. I think I came down a little hard and killed off
some useful discussion. I'll try and tread a little lighter next time.

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

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

Personally, I don't see the need. Obviously, some people do. Could
they explain the problem with the current scheme? Perhaps there is
a simpler solution such as DDL includes to pick up a common system
configuration.

Something I built into the DDL processor on my current program is
an "upgrade" DDL verb parallel to "create" (Oracle has the same
thing). An "upgrade" differs from "create" in that a) it doesn't
error if the thing exists, and b) it upgrades the old thing in place
with whatever it takes. An upgrade verb to defined UDFs would a
system wide UDF definition file to be included in DLL for target
databases to either define or update the UDFs.

I really prefer exploring modest extensions before jumping into
a radical change. Sometimes radical changes are necessary.

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

Golly, Bill, are you trying to reinvent the registry? Do you have
any of idea of what those Linux guys are going to do with you when
they catch on?

Seriously, consideration of a configuration file should start with
the need. So far we've agree that something needs to record database
mappings. Let's try to agree on what else makes sense before we try
to figure out the implementation.

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

File shares is something NT does pretty well. You don't have to be
on the console to edit the file.

In fact, I really don't like NT utilities that require you to be
on the console. We've got a small farm of systems here and wandering
from machine to machine to do some trivial task is really a drag.
This was the primary motivation for Interbase having only an API
open for everybody to use and fully supported by the remote interface.

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

This isn't consistent with Unix practice, which is to reparse only
when requested (usually with a HUP signal). For the record, I don't
like this either (I'm hard to please). I really like updating a
database by updating the database. It has a warm and comfy feel.
Less magic.

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

OK, syntax is a matter of taste. Next year the XML syntax will
look like Palladian windows on a house -- oh, so last week. XML
is the fad of the hour. I've been through a hundred of them. Some
stay, some don't. A Javabean, anyone? How about an applet on the
half shell? PC Solaris anyone? How about a Netframe? Tandem's
non-stop processing was going to take over the world. X-terminals
were the wave of the future. And Network Computers. And Lisp
replacing COBOL as a programming language. Prolog. Smalltalk.
All as big as XML is today.

>
>> 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 really don't think this is an issue. A authentication plug-in that
specifies an authentication file covers just about all bases.

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

Sounds good to me. A blob in a system table with an Apache-like
configuration string that specified the module and supplied parameters
would be dandy. No reason that multiple plug-ins could be specified --
no more work to implemented and they we don't have to argue.

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

Sorry, no. I want to configuration stuff in a blob in the database.

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

Not convinced. Lets keep at it.

Jim Starkey