Roman Rokytskyy wrote:

>Suggestions made in that discussion were supposed to simplify the API,
>remove the unneeded things (that either are not relevant to Firebird
>or return constants as most of the DatabaseMetaData calls do), etc.
>
>
>

And I explained that the API was defined to follow JDBC 1.2 as closely
as possible. The DatabaseMetaData calls are intended to let a client
know how about how the underlaying system handles things, just as in
Java. They are potentially useful to both Java code and non-Java
language processors.

The design is intended to support the thinest possible layer between a
Java JDBC based procedure and the database engine. You prefer a fat
layer, but someone else may decide that a thinner layer is faster and
less of a maintenance burden.

I don't think you should object to functionality that is useful to other
people just because you don't plan to use it. Besides, as internal SQL
changes, you might decide that these calls are actually more
informational than building in knowledge of all possible Firebird
version strings.

>>No language processor can be allowed to call internal functions that
>>can change from version to version. You should understand that.
>>
>>
>
>Yes, and I agree. The question is not what internal functions will be
>called, but what API is presented to the client.
>
>

Also how they are to be called and how transaction context is passed to
the language processor.

>I favor current ISC API as long as it is the API visible to normal
>applications and base for the wire protocol since it simplifies my
>life - JayBird has very similar architecture to Vulcan in regard of
>providers and Y-valve, however my "provider" interface is ISC API.
>Switching between internal and external modes means just using a
>different provider.
>
>

The problem is that the current ISC API is soon to be relegated to a
client side layer on top of a more efficient API. Much of what you
consider the current API disappears inside of the client side Y-valve
and isn't supported in the engine at all. Building in the old
SQLDA-based interface makes no sense at all.

>I have offered you to devote few hours in Prague and sketch the new
>API on paper. It is a pity that Dmitry and Vlad cannot join us there,
>but Paul Ruizendaal will be there for sure. Let's buy few beers (or
>anything you like) and start this.
>
>

If you have some ideas, float them now. If you think a database API can
be designed in a few hours over a few beers, I'm afraid you're in for a
disappointment. And given the reputation of the local brews...

--

Jim Starkey
Netfrastructure, Inc.
978 526-1376