Hi, Jim!

> The biggest problem with DSQL is that the API is close to unusable.
> Anyone who could love SQLDAs could love MPE/XL.

Yep.

> There would be, over time, three implementations of the interface.

One,

> inside the engine, would be used in modules to replace the existing
> pre-processed modules (met, dfw, ini, etc). Once complete, the engine
> could be build without preprocessor.

Yep, and allow to use internal implementation in C++-language stored
procedures. BTW, have you looked at Oracle lately? They have a nice
feature: if you use procedure often and it is computationally intensive
Oracle converts it to C++, invokes GCC and runs resulting native code.

> The second implementation would be a client side library implemented
> with the existing DSQL API. This already exists in OdbcJdbc and could
> be rolled out with next to no effort.

Jim, I'd recommend you to look at OdbcJdbc from time to time. Not all
changes happening there are good ones.

> The third implementation would be full integration of the interface

into

> the plumbing -- Y-valve, remote protocol, and engine. The third
> implementation, however, would be completely transparent. The client
> library would probe the Y-valve to see if it supported the new calls.
> If so, it would attempt to route a call through the plumbing. If this
> failed, it would do local emulation. This strategy would allow a
> network to gradually shift over to the new API without breaking
> anything. After a couple of reasons and due deliberation, the client
> library could disappear completely in favor of full architectural
> support of the new API.

Yep. Client library as a compatibility wrapper is the good idea.

> A problem not addressed is non-OO languages that couldn't use JDBC
> directly. A translation layer with handles would probably make most
> sense, though the old API would remain in place for the indefinite

future.

It is very easy to express object-oriented API in C language. I would
probably make external entrypoints "C" ones, but implemented thin inline
C++ wrapper to provide functionality you express. The problem that we
cure this way is instability of C++ ABI.

> Over time, the internal implementation and the internal DSQL could
> invert, with DSQL layered on JDBC rather than vice versa, backed up by

a

> pure SQL engine running in parallel to the legacy BLR engine.

I agree with you, but my view is slightly different. I would continue to
extend and maintain BLR SP/TRIGGER engine as it is already very nice and
is getting to become the most convenient to use in the industry.

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.

One of the biggest problems of Yukon is that everything runs in a single
process including user C/C++ code, COM objects and .NET runtime. When
something goes wrong this brings the whole system down and it is very
difficult to isolate the reason of failure. This problem becomes even
more interesting due to sensitivity of IA64 architecture to garbage
hidden in 65-th bit of registers.

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

Installation partitioning is completely transparent to everybody and may
only introduce a slight performance penalty which is negligible given
recent OS technology advances.

> None of this is going to happen as part of Vulcan, though I must admit
> that dumping the internal gpre-ed modules is mighty tempting. But I

do

> think that this is a good time to discuss it.

Many people here understand what needs to be done with Firebird,
actually. The usual Open Source problem is lack of resources and
coordination.

> Jim Starkey

Nickolay