Hi, Jim!

> The basic idea, however, is the API is defined in terms of objects,
> methods, and exceptions. Wrappers and legacy APIs are available for
> non-OO languages. I don't think we should feel bad about neglecting

old

> languages as long as we keep the legacy API up and working. The

future

> (hey, even the present) is OO.

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.

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

> >I would implement internal SQL API and implemented multi-language SP
> >layer using this API. As a result we would get possibility to write

SP

> >in Java and C++. But I would keep those subsystems separate, of

course.

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

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

> >Oracle addresses this problem in a clever way. It allows you to
> >partition your installation and run various subsystems in different
> >processes.
> >You may run some of your dangerous C++ procedures in one process, JVM

in

> >another process and SQL engine in the third separate set of

processes.

> >In Oracle, PL/SQL engine is one more client to SQL engine, but that

was

> >bad idea, I think (do you like bulk binding in PL/SQL and 2 separate
> >parsers? Most people don't).
> >
> If you're looking for a way to be really slow, doing two context
> switches on every record is a tried and true solution.

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.

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

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

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. Even if it
is true to some extent, I'm more pragmatic and know that everyone's code
is crap including yours, Jim, and of other JVM and OS writers. I can
hack into every OS, JVM or database given enough time because each large
piece of code has bugs that may be exploited. This is the fundamental
property of human nature. The idea behind secure and reliable systems is
to produce layered structure of isolation and fail-over.

> C++ programmer can learn that they can leave 95% of C++ crap behind
> leaving just the good part. They'll whimper at first, then love you

for

> it.

Ok, let's rewrite our JVM's in Java and get happy. :)

> Jim Starkey

Nickolay