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

Before I can comment on this I have to check the Vulcan sources first.
There are few candidates that most likely do not have corresponding
support in Vulcan.

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

Which would require then implementing another JayBird - one for old
ugly API (is already there) and one for nice OO API. Now, if we
consider new wire protocol implementation and if conceptually it will
not be based on either OO API or "ugly"-API, we get the third JayBird
implementation. Not that I am very happy with it. But even if we
ignore my happiness, this path requires a lot of work and time.

> It will probably track JDBC, but there isn't much in JDBC 3.0 or 4.0
> that is particularly important or even interesting.

Exactly, all that is mostly not so important things, but they
constitute the JDBC X.x compatibility. It does not matter if we think
that the feature is important or not, matters what other think of it
(and in most cases this is all about a checked checkbox in the feature
list).

As an example take a scrollable and updatable result set that is not
supported by Firebird. This type of result set is expected by the Sun
RowSet implementation. The RowSet API is used now in many different
components/applications. It was not possible to use them with Firebird
till JayBird 2.0 which emulates them by caching all the stuff in
memory. So, the same feature has to be emulated there too.

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

Since we are going to support old ugly API on top of nice OO API (it
will be on top, isn't it), why cannot we export the same old ugly API
for those that want to use it for external procedures, basically those
that already have database access components and want to use them to
access the engine?

I suggest to keep out "ugly" API and provide it for applications and
external procedures. This we can easily do in FB 3.0 (FB 3.0 is just a
merge of FB 2.0 and Vulcan in our roadmap). Later, when our new API
becomes a reality, we provide it both to the applications and external
procedures.

But again, we moved away from the document. It was not about the
engine API that is passed to the external procedure (that was supposed
to be separate discussion), but about the API that external procedure
has to implement. You suggest to use existing ResultSet class instead
of the one suggested in the document. Right? Now the questions to your
ResultSet concept:

- are strings unicode? if not, how does the code that uses ResultSet
get information about the character set? note that XSQLVAR contains it
already.

- how blobs are passed - by ID or as a stream? if former, are blob
routines part of the result set interface? if latter, how does
application know the charset for clobs? note, this information is
available in XSQLVAR.

- are timezones handled by the result set for timestamp? if not, in
which timezone they operate and how to get that timezone? note, we
have default timezone for JVM, but not for the server.

- does ResultSet perform the type conversion, e.g. can we call
ResultSet.getString(int) method for an INTEGER field?

Roman