> If we're going to support arbitrary language processors inside the
> engine, and I think we should, we need to define a functional,
> stable bi-directional API between the engine and the language
> processor.

Agree.

> I've offered an industry accepted API (JDBC) defined as an abstract
> interface. As a Java programmer, you understand that an abstract
> interface isolates the interface client from the implementation.
> The interface has separate implementations for inside the engine
> (InterfaceConnection) and as a layered interface (IscDbc). I know
> you don't like (you are argue both that it has some things you don't
> need and doesn't have other things you don't need), but you are
> unwilling to make constructive criticisms or suggest an alternative.

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.

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

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.

> So the next step is to define a supportable abstract interface
> between the engine and the language processor. Until you are
> willing to participate in that process, your proposal is going to go
> nowhere, regardless of how much we all want the capability.

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.

> This is not acceptable. We either make the effort to do it right or
> we don't do it.

And only after we (you, Dmitry, Vlad, Claudio, Paul, etc) get it right
and agree on it, I will change JayBird to support what we have done.

> The merge will no effect on the requirements or design of a language
> processor API. If your design is based on internal, implementation
> specific functions, it will be just as unacceptable for FB3 as it is
> for Vulcan.

The proposal did not include the API itself, but the API of calling
procedures and functions. Things are open when we talk about the
callback API, but without agreement on the API it makes no sense to
continue that work.

Roman