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

Will see ;)

> Paul, this means the Fyacle and Roman's external procedure mechanism
> will not run with Vulcan.

It will run on Vulcan as long as Vulcan will support isc_XXX api.
But i doubt about plans to porting Fyracle on 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.

AFAIK, Fyracle never stated to be merged into Firebird.
...

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

To which part of proposition you refer ? As i can see Roman's proposition
don't break anything. Where you see description of engine callbacks in his
proposition ?

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

Do you want to completely discard old isc_XXX api in Vulcan\FB3 ?
...

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

I hope not all share your hot love to Java only ;) Fortunately Java
not only language in the world


Regards,
Vlad