Roman Rokytskyy wrote:

>The jrd8_XXX calls are available in the engine in Vulcan and could be
>used instead of the isc_XXX calls to solve the layering issue, but you
>intend to remove them too. Finally a mapping between Vulcan JDBC API
>and current public ISC API is possible, so the layering issue can be
>resolved in Vulcan and current solution is implementable there too.
>
>

I've tried to explain the difference between an external, controlled
interface and an internal interface, without success. Cutting to the quick,
the jrd8_xxx calls an internal interfaces subject to change without
notice or even disappearing completely. You can't design a plugin
architecture without an explicit definition resources available to it
including the API. I know that it has become part of Firebird culture
that every release should break everything, but this isn't the way
things should or can be.

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.

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.

No language processor can be allowed to call internal functions that can
change from version to version. You should understand that. 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.

>Yes, since there is no agreement on using that interface as main
>interface to the engine and I am inclined to support two different
>code bases for different API especially when one of them is not
>finalized and supporting it would require substantial driver changes.
>
>

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

>The FB/Vulcan merge must resolve this issue either producing single
>API for internal and external code or producing two different APIs.
>
>

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.

--

Jim Starkey
Netfrastructure, Inc.
978 526-1376