==========================================================================
* Forwarded by Roman Rokytskyy <rrokytskyy@...>
* From: "Samofatov, Nickolay" <Nickolay@...>
* Date: Thu, 1 Apr 2004 16:12:07 -0500
* To: "Roman Rokytskyy" <rrokytskyy@...>
* Subj: RE: [Firebird-Architect] Re: External procedures: call for
discussion
==========================================================================

Hi, Roman!

>> Even if they will be "external procedures", can the "external
>> function" API be upgraded to the same mechanism?
>
> Might be. However preference should be given to the languages
> executing a code in a sandbox manner in order to avoid
> current problems with incorrect UDFs that we have.

Optional usage of IPC between external modules allows to isolate
failures and make C/C++ act as a sandbox language.
Oracle allows you to partition UNIX installation to move JVM, native
routines and PL/SQL engines out of SQL engine core processes to a set of
named worker processes. You can move individual routines and packages
between the processes without any changes in their code. This makes
debugging of "strange" problems possible and allows applications to work
reliably even in presense of untrusted C/C++ code.

Creating a small and optional CORBA framework to export engine API and
invoke procedural engines to make this IPC possible for Firebird is
quite easy. I used OmniORB in my tests and it worked quite fine except a
couple issues with DLL unloading in Win32 embedded case, but we may
avoid using this technology for this particular target.

One of the biggest problems Microsoft has with Yukon is that they run
NET framework inside the database engine and it is very difficult to
isolate and trace out reason of failure when something goes wrong.
This makes DBA difficult to be responsible for database side because he
has to care of .NET code. Big clients didn't want to see it this way.

Now MS folks are rewriting some major parts of their new functionality
to allow running Yukon server without .NET engine inside.

I know this details because MS people did presentation on this subject
in BroadView not so long ago.

Nickolay

==========================================================================
With best regards, Roman Rokytskyy. E-mail: rrokytskyy@...