Samofatov, Nickolay wrote:

>Yep, but there is no standardized method of passing exceptions and entry
>points between OO systems (except of super-heavyweight COM and CORBA, of
>course). As an exercise, try to import exported C++ class into Delphi or
>Kylix program.
>
>

Yes, I know. We should made an canonical API for C++ and let developers
using that API to write wrappers for other languages. There really
isn't much of an alternative.

>>I concur. But we probably want to move the SQL path off the BLR
>>engine. There is no reasons that multiple engines can exists on the
>>execution layer (evl and rse).
>>
>>
>
>This is questionable. I would let SQL and PSQL be tightly tied with
>execution engine because of the performance reasons. And global
>invariant optimization in procedures is the nice idea, really. It
>already works, to some extent, now.
>
>

It's not big deal, really. An alternative engine cases off SQL verb
rather than BLR verb. The top level interpreter is trivial.

>>Never C++!!!! Sandboxed languages only!
>>
>>
>
>Cannot agree with you here. Do you remember that sandboxed languages are
>written in C++? For example, Firebird PL/SQL engine developed to run
>Compiere on Firebird may become one of such subsystems.
>

The engine is written in C++. It is trusted. An ebedded JVM or BLR
interpreter or PL/SQL (gag) interpreter are all trusted. Arbitrary user
supplied code is never trusted and unless sandboxed in a separate
process, unthinkable (although we current allow it and shouldn't but
don't have an alternative).

>
>But sandbox violations sometimes happen; this is why failure isolation
>is generally good idea.
>

Wrong. Fix the sandbox. A simple call is infinitely faster than a
context switch.

We're writting a database system here, not an operating system.

>1) This is ok when you need to trace out the problem or make system work
>even if something is wrong in it.
>2) Context switches are not that slow now.
>3) We may add bulk binding API's to external language engines. It is
>needed for client side anyway.
>

1) No. 2) Wrong. 3a) I disagree, 3b) I've already addressed the local
engine API. It's the same API.

>>I don't want to have dangerous C++ procedures. More to the point, I
>>don't want somebody else's dangerous C++ code anywhere near my data.
>>
>>

If it's firebird code, it's trusted. If somebody else plugs it in, it's
not trusted.

>:) This is impossible. When you need to interoperate with other systems
>you have to resort to C++ or even C code.
>

Explain, please.

>It looks like you tend to build your own world using your own code only
>and threat everyone' else code as crap that should be isolated while
>your code is perfect and cannot benefit from such isolation.
>

You're beginning to catch on. A database system is responsible for the
correctness of it's internals. If we include something and it screws
up, it's our fault. We vouch for our subsystems. That's the way it is
and that's the way it has to be.

--

Jim Starkey
Netfrastructure, Inc.
978 526-1376