At 01:46 AM 5/3/00 -0400, Claudio Valderrama C. wrote:

>And where should be it kept? You want to see isc4.gdb to be demoted from its
>key status.
>Do you think all metadata can be kept in each specific database?
>

Yes, I do. I think the idea of a system wide configuration is
il-considered and unwise.

Although we are rapidly entering an era of single use computers, this
is not yet universal, and history has demonstrated a tendency to
flip flop. For planning purposes, we should consider that servers
are multi-use. As such, there is no guarentee that various projects
will want to share a common name space for UDFs. An ISP running
a large, shared server among many clients who are unaware of each
other existence. Management of a central configuration file and
a single UDF (and potentially other object) namespace is a burden
if it is possible at all. Even on a single organization server
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. There are
many variations on this theme.

How does a someone install a turnkey system? Under the current
philosophy the files are installed in appropriate places and
the database either created from ddl or gbak restore. Under
the configuration schema, either the person installing the
application would have to edit the configuration file (and
understand it, etc.) or the application vendor would have to
write and maintain a non-trivial program to update and arbitrary
configuration file. Given that the config file is essentially
open ended, this is a problem.

How do two users (or two programs) simultaneous update a configuration
file? I suppose we have to depend on file locking and just hope
that all tools use to edit the file use the right modes? So
what happens to an install script that tries to edit a locked
config file? It fails. How can you find out who has it
locked? You can't. What happens if two guys or two tools
go at it without locking the file? The second guy to write
trashes the first guys updates. How does the first guy find
out? He can't.

When does the engine reparse the configuration file? Does it
stat the file on every attach? On everything compile_request?
Or just when we send it a HUP? Or do we have a special call
to refresh the configuration file?

What does it do if it finds an error in the config file? Apache
croaks. Is this a good model? Should the server continue with
the old configuation? Who does it tell that the file is bad. The
first application program that shows up? Lets see. Somebody
blows an update to the config file. The first application is a
data entry program. Assuming the application programmer did a
good job of error reports, the data entry clerks gets a message
about a bad config file. Great. He tells his supervisor who
calls his VP who calls the IS VP who calls who?

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?

In Interbase philsophy, like virtually all RDBMSes, is that each
database is administered autonomously. This allows the database
developers and users to control their own environment rather than
requiring intervention of system managers. This model has worked
well for 16 years. 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.

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

As I have said, I don't object to the existence of isc4.gdb.
There are problems for which it is an appropriate solution.
But I don't think it is a good default solution. I would
like the first authentication plug-in be support for isc4.gdb
for compatibility so we can back away from it in favor of
Apache style authentication lists.

Jim Starkey