Nando Dessena wrote:

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

The difference is that now significant process and data
conversion/copying is required every time a DSQL data call traverses a
layer. Every dsql fetch operation requires a SQLDA analysis, generation
of a blr string that describes the SQLDA, parsing the blr string, and at
least three complete copy operations for all data items. I want to
eliminate the overhead and all of the intermediate data
copy/conversions, simplify the line protocol, and deprecate a large
amount of inefficient, unnecessary code.

The existing XSQLDA interface is designed for languages that support
fixed fields and datatypes, e.g. COBOL and RPG. Modern languages (and
interfaces) support abstract things like "String of arbitrary length"
rather than "String, 2 byte count, fixed maximum length". The JDBC
interface, for example, has simple PreparedStatement.setString(int,
String) and ResultSet.getString(int). The code that implements these
calls must have access to metadata to know what kind of fields to
generate in an XSQLDA long before it sees the user data. Ironically,
at the far end of the plumbing, the engine itself deals with abstract
data. I want both ends of the plumbing to be able to deal with abstract
data, have the interface edges serialize it, and the far end do only
those conversions necessary to translate the data from original form to
what is needed.

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

It isn't at all the same. The existing mechanisms uses a visible
physical data structure that is both expensive to process and
constraining to extension..

The original API was indeed object oriented, with all data and metadata
passed as messages. I want to replace messages of fixed length fields
described by external blr with self describing messages with embedded
type information. I also want to replace the SQLDA based API with an
API faithful to the original DSRI/OSRI design principles.

Object oriented means encapsulation and polymorphism. Encapsulation
means you can't look into the object, only call methods. Polymorphism
means that two equivalent objects could have different implementations
of a method. Object oriented doesn't say anything about language
syntax. It makes no difference whether a method call is expressed:

handle->method(arg1, arg2)

or

method(handle, arg1, arg2)

It does, however, make a great deal of difference as to what arg1 and
arg2 are. If they are pointers to know data structures, it's not object
oriented.