> A couple of things. First, I don't think loadable library names
> belong in metadata, period. Information about loadable services
> should be in the configuration file.

Ok, I think I agree on this one when we talk about the engine plugins.
But what is your suggestion for something like UDFs, at least of the
same level of complexity?

> Second, Vulcan already has a set abstract class
> definitions for JDBC-type objects that form the basis for internal
> SQL. These should service as the basis for communication between the
> engine and an external engine.

I expected this "complaint", the only excuse is that this thing was
designed and the first prototype implemented at the same time you
started to code Vulcan.

But let's look into the future:

How would it work for a simple external procedure written in C++ just
because of some complicated computation? And what about Delphi? Don't
we have the same problem we had when we were talking about the public
OO API and entry point names in the DLLs?

I have to admit that the paper does not address the issue as well. So,
my question here is - should we address external procedures that have
an API complexity similar to current UDFs?

Roman