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

See below.

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

Not compatibility, but letting people to work with the components they
are used to.

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

As I said, if after merge Connection interface becomes the official
internal API, I will think what to do next - wrap it with ISC-like API
to simplify the life, or to rewrite parts of JayBird to fit into the
picture, and please be sure that I will check the performance and
maintainability benefits of both solutions. If not, I will think about
the new interface.

> 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, I never objected the fact that layering should be restored and I
do not object to something that I do not need but it is useful for
others.

However, together with restoring layering you try to sell me are:

- C++ interfaces to access the engine that were never discussed in
that context;

- compatibility constraints for them (like full-text seach API from
Netfrastructure which was never discussed and calls currently throw
errors, since they are not implemented);

- guidelines for interface extension (the extension must be generic
enough to use it in other products like OdbcJdbc driver, and possibly
Netfrastructure).

- the ubiquitous Unicode usage on the API level.

None of this was either discussed or accepted by the core team so far.
And that is what I object to.

And for now, in order not to screw things up in the engine I simply
stick to what I have, basically the ISC-like API.

Roman