Bill,

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

FWIW, I don't like that much the idea of having access to
library functions without declaring them. I don't know of
any programming language that permits it. Surely it would
help in the case you want to provide functions which look
like the predefined (internal) ones, but I don't see it a
big advantage.
My 0.2 Euros.

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

I believe we should now try to separate what can (and
should) be put in each database, what must go into a central
repository and what (if anything) still gives ISC4.GDB a
reason for existence.

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

I second this point of view.
--
_____
__/\/ando