"Jim Starkey" <jas@...> wrote:

>
> 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. In specific, the engine should pass an instance
> of Connection to the external procedure. The external procedure, if
> appropriate, should return an instance of ResultSet. The abstract class
> definitions are tightly modelled on JDBC and essentially the same as
> those used in the ODBC driver (they once were the same, but the ODBC
> driver code diverged). I expect these class definitions to form the
> basis of the new OO API at some point in the future.

Everything exported from the engine is a public API. This highly restricts
any changes in the IscDbc interface. And this also means that IscDbc _must_
become an official public OO API in the future, as I'd hate to see two
different concurrent API class sets. Considering all of this, IscDbc is not
even near to be used this way. So I'd suppose that the first ESP
implementation will use the old-style API (or perhaps the Provider
interface). But let's discuss this a bit later, as Roman suggests (I'm sure
the ESP callbacks discussion will be initiated shortly).


Dmitry