Dmitry Yemanov wrote:

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

Sorry, but the old style API doesn't work inside the engine, so it isn't
an alternative.

The IscDbc interface (vulcan/src/common/Connection.cpp) is both stable
and extensible. The version used by the Vulcan IscDbc library is a
slightly older version and should be upgraded to the one in common. The
version used inside the ODBC driver has drifted too far to generally
useful, and should be considered as an internal interface within the
ODBC driver.

Philosphically, I'd like to see the same abstract base classes used in
engine, in the IscDbc layer, and in the new OO interface. It probably
won't be a surprise to any to know that these are also base classes for
the Netfrastructure interface, where it used for both the internal
engine and external interfaces.

--

Jim Starkey
Netfrastructure, Inc.
978 526-1376