Jim,

J> The lower level interface I'm proposing isn't necessarily intended for
J> general application use, but as a single layer that will support the
J> existing DSQL api, a C++ JDBC-style interface, and, theoretically at
J> least, a "native" JNI backend for a thin JDBC driver for embedded use.

I don't get it. Meaning I don't get what's different from what we have
now. Would the C++ JDBC-style interface and JNI be layered on top of a
lower level API, or would they be published side by side to it? In
both cases it's not "a single layer", is it?

J> It doesn't both me if other languages can't access it directly as long
J> as a thin, cheap interface layer can provide good and appropriate API
J> semantics. The actual API should be designed to be implementable as a
J> very thin layer on a simple wire protocol, with state residing
J> implicitly in the application program and explicitly in the server/engine.

which I thought is more or less what's currently in ibase.h; you could
redesign it to make it more network- and object-friendly, but the
basic mechanism is exporting plain old extern "C" functions. In
summary, I can't see what's revolutionary in what you propose. Someone
please enlighten me :-).

Ciao
--
Nando Dessena
http://www.flamerobin.org