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

> Huh? We were talking about an internal engine API exportable to
> language processors. What does that have to do with IBX, et al?

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.

> Nobody has suggested that the load language processor interface be
> backported to Firebird 1.0 or 1.5, so I don't see your point.

Sorry, I though we talk about using JayBird for Java.

> Roman, the external API doesn't exist inside the engine in a
> supportable manner. Just get used to that idea.

Ok. Then I wait for a finalized internal API.

> Let us get this straight. You want to screw up the internal
> architecture of Firebird so you don't have to change your code. Is
> that the only real issue here?

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.

Roman