|Subject||Re: Java Stored Procedures|
> If we're going to support arbitrary language processors inside theAgree.
> engine, and I think we should, we need to define a functional,
> stable bi-directional API between the engine and the language
> I've offered an industry accepted API (JDBC) defined as an abstractSuggestions made in that discussion were supposed to simplify the API,
> 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.
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 thatYes, and I agree. The question is not what internal functions will be
> can change from version to version. You should understand that.
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
> So the next step is to define a supportable abstract interfaceI have offered you to devote few hours in Prague and sketch the new
> 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.
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 orAnd only after we (you, Dmitry, Vlad, Claudio, Paul, etc) get it right
> we don't do it.
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 languageThe proposal did not include the API itself, but the API of calling
> 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.
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.