> The major hangup is an architecturally acceptable interface. The
> "proof of concept" breaks the product layering

It breaks layering only because other is not possible in FB2.

> and is unimplementable in Vulcan. The issue has to do with how SQL
> callbacks are performed. In the proof of concept, database access
> had to be through the XSqda calls which are inaccessible from within
> the engine.

And that's another story.

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.

As to the performance, you said that Vulcan-JDBC/ISC API mapping must
be as fast as current FB2, since Vulcan JDBC calls are significantly
faster, so mapped solution would be at least as fast as current one,
maybe faster.

> There are JDBC based interfaces available (IscDbc for FB2 and
> InternalConnection), but Roman rejected the idea of using JDBC for
> communications between the JVM and the database engine.

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.

The FB/Vulcan merge must resolve this issue either producing single
API for internal and external code or producing two different APIs.
After that Java SPs round can continue - we will design new plugin,
modify JayBird to support new API, etc.

Roman