paulruizendaal wrote:

>In this light, I am happy with the external procedure proposal. It
>can be implemented quickly and runs efficiently. It is good enough for
>the Fyracle releases based on 1.5.x and I do not care at all that
>layering is broken (it already is, so nothing is lost). I am striving
>to have this implemented by the end of August, regardless of
>architect list discussions.
>
>

Paul, this means the Fyacle and Roman's external procedure mechanism
will not run with Vulcan. I think it is a serious mistake to implement
a major feature knowing that it cannot be supported in the future. If
you need that feature in the immediate feature, I think it would be
better if you maintain it in your private tree and not attempt to merge
it into Firebird.

Splitting "the server" into separate libraries for the client library
and providers is critical for future development. Without the ability
to access gateways to Interbase, legacy versions of Firebird, and
multiple engine versions it will be very difficult to move Firebird
forward in the future. It would also mean writing off Vulcan, which I
hope nobody is willing to consider.

I haven't the slightest objection to Roman's external procedure
mechanism appearing in a private version, but I have a great deal of
trouble understanding how we can accept code that breaks our
architecture and can't be integrated with versions now under development.

>
>For instance, it would be possible for the engine to expose a jdbc-
>style connection object and for the external SP interface code to
>expose a isc_* api like call interface, generating its own handle
>id's on the fly, just like the Y-valve currently does. The IscDbc
>code builds a jdbc-like api on top of the isc_* api; the reverse is
>equally feasible.
>
>

That could be done, but would be horribly inefficient. The internal SQL
is designed to bypass the SQLDA handling, and consequently is
significantly faster than DSQL. Taking Java JDBC code, turning it into
DSQL API (SQLDAs and all) then remapping the DSQL back to JDBC strikes
me has a miserable exercise in creative squandering of processor cycles.

>In my mind, the big question for FB3 external SP's is not so much the
>API, but how to isolate failures in the external code from messing up
>the engine. PL/SQL, java, .net/mono could perhaps be supported "in
>process" with sufficient stability, but how about everything else?
>
>

Failures, basically, can't be contained. There is nothing that Firebird
can do to detect, prevent, or recover from external code writing random
stuff in the virtual address space. I have never liked running external
code in the engine, but until Java, there was no alternative other than
to forgo UDFs and blob filters. With Java, we can remove the liability
without sacrificing user extensibility.

Personally, I care less about multiple language support inside the
engine than other people seem to. I would be completely content with a
fully functional, highly integrated JVM that enforced a proper sandbox.
Java provides a very good balance between flexibility and performance,
and supports one of the better OO database APIs around. So I'm not
convinced with need a general solution at all, just a very high quality
Java facility. I'm not necessarily against other external procedure
languages, but I'm sure we have to lean over backwards to make it easy.
If we can agree an a generic API, fine. If not, then lets put Java at
the head of the line.


--

Jim Starkey
Netfrastructure, Inc.
978 526-1376