Roman Rokytskyy wrote:

>>It shouldn't be. The abstract class ResultSet specifies only the
>>API, not the mechanism behind it. An Java implementation of
>>external procedures would probably return an implementation of
>>ResultSet that navigated the corresponding Java objects with JNI.
>>
>>
>By requiring this you say one of the following:
>
>- External Java SP gets less featured JDBC implementation (something
>like JDBC 1.2 level)
>
>

First, the various abstract classes (think of them as Java interfaces)
can be extended as has JDBC itself. There is nothing about the
architecture that constrains what we do in the future. No matter what
you do, you are constrained by Firebird SQL. The abstract classes give
you everything is is available. I suppose you could go in at the BLR
level if you really want, but I doubt that you do.

>- Two versions of Java accessibility components will have to be kept
>in sync - one for public API (currently our lovely ibase.h) and one
>for internal API.
>
>

We will continue to support the existing external API, probably
forever. But as an API, it stinks. SQLDAs and SQLCODE codes are a
miserable way to write code. It wasn't even particularly nice in 1986
when I borrowed it from DB2. And it hasn't gotten any better. A nice,
simple, OO interface that significantly reduces the cost of the various
transmission layers is the way to go.

>I am not sure that I accept any of the above. So, the only possibility
>is to have same API for the client and for the server (or you're going
>to upgrade your internal JDBC-like interface to be JDBC 3.0 and soon
>JDBC 4.0 compatible).
>
>

It will probably track JDBC, but there isn't much in JDBC 3.0 or 4.0
that is particularly important or even interesting. It would be silly
to say no, but I don't think anyone really cares. The goal isn't to
support a JDBC interface, though that does fall out for free, but to
have a well designed, stable, modern OO interface.

>Didn't we agree that public OO API is a nice thing, but is not
>applicable to all situations?
>
>

Of course. Nobody has even suggested retiring our very ugly API. But
this has nothing to do with exporting internal SQL to an external
procedure. That already exists inside the Vulcan engine.

>How are we going to convince all connectivity component developers to
>throw away everything they did till now and to recode the components
>for a new API?
>
>

We're not. Anyone who wants their programs to stay slow can continue to
use the existing API. But again, we're talking about internal engine
SQL suitable for export to a loadable external procedures library, not
the external API.

>Or we are going to maintain a C and C++ APIs for next Firebird versions?
>
>
>

I think we want to define a low level, pseudo OO, language independent
API with two primary clients. One is the existing, soon to be legacy,
API using SQLDAs and SQLCODEs. The other is a higher level, JDBC-like
interface with a set of language specific instantiations.

--

Jim Starkey
Netfrastructure, Inc.
978 526-1376