> >What did you think of the architecture that I described the other day, in
> >which functions could be declared globally in the config file ...
>
> Personally, I don't see the need. Obviously, some people do. Could
> they explain the problem with the current scheme?

The need is that folks have a need for a certain set of "staple" UDFs in
nearly every database. Strlen, Rtrim, DayOfMonth, stuff like that. Folks
(including myself) find it repetitive and seemingly unnecessary to declare
commonly needed UDFs in every database.

> Perhaps there is
> a simpler solution such as DDL includes to pick up a common system
> configuration.

Yes, we do have an include mechanism for isql (the "input" command), but
that's still an extra step that one has to remember to do. The proposed
solution would enable _all_ databases on a system to have access to a
certain set of common UDFs _without_ having to declare them all.

> Something I built into the DDL processor on my current program is
> an "upgrade" DDL verb parallel to "create" (Oracle has the same
> thing).

That's neat. Would solve some people's schema maintenance tasks.

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

Maybe isql needs a "~/.isqldefaults" file for commands to run automatically
upon startup (I think qli always had this) or when certain other statements
are invoked, such as CREATE DATABASE. Then one could define a set of
DECLARE EXTERNAL FUNCTION statements to run automatically every time one
creates a database.

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

Hey! Not a bad idea. Perhaps it's something I could do, and offer as a
freeware package on www.karwin.com as a project unrelated to InterBase...
;-)

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

I think it's been made clear that there are many other things one could put
in this config repository (whatever the mechanism). Like everything that's
currently in isc_config, and the authentication plug-in information, etc.

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

Good point. I hadn't thought of that, because I assume that InterBase
server directories should never be shared, for security reasons.

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

Neither do I like this method. Forcing inetd to re-read its configuration
with a HUP signal is a nuisance. That's why I suggested the server re-read
the config file automatically when the timestamp changes, but not until some
module in the server requests a config item.

This would of course be simpler if the config information were kept in
system tables where possible.

> XML is the fad of the hour

I'm not necessarily married to XML. (okay, I do have some equity in it ;)

I just thought that *if* InterBase uses a flat config file implementation, a
well-known structured text standard is probably preferred over a propriety
format.

> A blob in a system table with an Apache-like
> configuration string that specified the module and supplied parameters
> would be dandy.

Doesn't it kind of defeat the purpose of storing the config information in a
database if you're going to store it as a textual representation in a Blob.
You can't query or set individual elements with SQL statements. Your
version control is all-or-nothing. If you provide syntax validation, you
have to build it into the server. You lose the accessibility of editing the
config with vi. You also need a front-end tool (either isql or a
specialized tool) to view the configuration if you just want to simply check
something.

> >> 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 [the] configuration stuff in a blob in the database.

Sorry, this wasn't what I was getting at. I just meant that it was logical
for authentication details to be associated in some way with a given
database Alias. It's not necessary that these details are stored in an
external config file, even if Alias mappings are.

For example, if the authentication details are stored in the database, then
the sequence might be:
1. The Y-Valve maps an alias to a database file, and the engine readies the
database with no authenticated InterBase user ID set.
2. The access method finds authentication info in the database's system
tables, and connects to the authentication server.
3. Identify and authenticate the user. If successful, set USER
appropriately and proceed to allow requests. If unsuccessful, return
authentication error message and disconnect from database.

Another neat option that the authentication-per-Alias provides is that one
could theoretically configure multiple Aliases that point to the same
physical database, and each Alias would have a different authentication
scheme! That is,
CONNECT 'dbserver:Employeegdb_NIS' USER 'root';
CONNECT 'dbserver:Employeegdb_ISC4' USER 'sysdba';

Bill Karwin