Nando Dessena wrote:

>Jim,
>
>J> There are probably other strategies worth exploring. But the
>J> polymorphism and encapsulation properties of an object API do justify
>J> the effort to solve the problems.
>
>I think that the handle-based approach that most cross-language APIs I
>have seen suits an object oriented encapsulation well enough. That
>encapsulation would have to be done in the target language, though.
>
>One approach to doing that is what Borland did to make Delphi use QT.
>QT is a C++ library with a C++ interface, unlinkable by the Delphi
>compiler. So they wrapped the C++ classes into a POF- (plain old
>functions <g>) based adapter API, with one function for each member
>function of each class (plus constructors, destructors & any globals).
>All the functions took a handle/pointer to use as "this". They then
>wrapped the wrapper into a Delphi class library. This is not the best
>possible setup efficiency-wise but it worked. I can't see how one
>would make a Firebird C++ API available to languages other than C++
>without going through a lower level layer like the one I described
>above, which doesn't sound too different from what happens now, except
>that now an OO native API is not available even for C++ (but that is
>easily solved by bundling IBPP with Fb :-)).
>
>
>
>

The lower level interface I'm proposing isn't necessarily intended for
general application use, but as a single layer that will support the
existing DSQL api, a C++ JDBC-style interface, and, theoretically at
least, a "native" JNI backend for a thin JDBC driver for embedded use.
It doesn't both me if other languages can't access it directly as long
as a thin, cheap interface layer can provide good and appropriate API
semantics. The actual API should be designed to be implementable as a
very thin layer on a simple wire protocol, with state residing
implicitly in the application program and explicitly in the server/engine.

Thin clients are good. Thin, dumb clients are better. Thin, dumb
clients with lots of money and a willingness to part with it are the best.


--

Jim Starkey
Netfrastructure, Inc.
978 526-1376