Roman Rokytskyy wrote:

>>No, it doesn't mean that. It only means that the functionality
>>available in Firebird can be captured in JDBC 1.2. It can be
>>extended, but it doesn't have to be.
>>
>>
>
>Consider the recent implementation of INSERT ... INTO ... RETURN.. ISC
>API did not require any change to support this construction. Support
>for this feature in JDBC changed the java.sql.Statement and
>java.sql.PreparedStatement interfaces.
>
>

Interfaces are extensible. If we need to extend it, we extend it.

>Then you have missed the point. The target is external procedures
>written in different languages, including C++ and Delphi, not only
>processors that either require p-code engine or a scripting language.
>
>

No matter what API is defined, code with have to written to make any
language processor work with the engine and use that API. As for target
code, since there currently any Firebird procedure code written in
Delphi, C++, or Java, compatibility isn't a factor. Whoever writes the
language processor has to cope with the API. I'm quite satisfied that
virtually anything can be mapped to and from IscDbc (after all, it was
the basis for the ODBC driver, which covers a multitude of sin of
omission and comission).

>Ok. Then I wait for a finalized internal API.
>
>

The Connection interface is the internal SQL API and is layered on
CStatement, the engine compiled SQL class. Writing another API that
supports SQL is a huge amount of work, and given that the FB2 guys have
zero interest in using SQL internally, the chances of another interface
are mighty slim.

>
>
>Definitely not. Since you view my participation as an attempt to screw
>things up, than I simply stop this discussion and wait until core team
>presents me an interface. That's basically what I said - there is no
>agreement on the API, you do not accept proposal made by me, Vlad and
>Eugeney, I personally do not like your API. Since I'm not core engine
>developer, I simply wait until a new API is presented. After that I
>will think what is better - to support new API or to map it into the
>ISC API considering the performance and the code maintainability.
>
>
>

You've made two objections: 1) it has stuff you don't need, and 2) it
doesn't have other stuff that you don't need. I don't consider either
as even marginally serious arguments. I have given you the reasons
that you can't call internal functions and why the external API can't be
used without breaking the layering now and can't be used at all with
Vulcan and future versions.

--

Jim Starkey
Netfrastructure, Inc.
978 526-1376