Jim, thanks for your very prompt reply.

I'm not sure I understand just what you are doing/proposing:

Lets say || means process boundary.

As I understand it interclient is now

(1) firebird || interserver | network | interclient/rest of java program

It seems there is one too many process here.

Are you proposing

(2) firebird + C++ ODBC | network | thin JDBC + rest of java program

or

(3) firebird | network | C++ ODBC / JNI-JDBC + rest of java program

or something else?

If (2), forgive my density, but where does JNI come in?



Is the JDBC stuff you are working on going to support the XA stuff? ( or is
this secret?) Any ideas when it might be available?

Thanks again
David Jencks

On 2001.02.20 11:01:35 -0500 Jim Starkey wrote:
> At 10:55 AM 2/20/01 -0500, you wrote:
> >
> >So I am wondering if Jim could present a few hints or comments as to a
> >desirable architecture for a JDBC driver. Does it involve his ODBC
> driver?
> >If so, is it, realistically speaking, likely to become open source in
> the
> >forseeable future?
> >
>
> I have been an advocate of a C++ API based on JDBC object structure
> and semantics, initially layered on the Firebird API. The API
> would be useable directly, as an underlaying API for a generic
> ODBC driver, and the basis for a very thin Java JDBC driver
> (essentially a JNI bridge between the skeletal Java classes
> and the C++ API).
>
> There are two other open source projects following the same
> strategy, but slightly different instantiations. The primary
> differences are string handling and object lifetimes (the
> more popular of the two has significant architectural problems
> on Windows and MSVC++).
>
> The IBPhoenix ODBC driver is, in fact, an implementation of
> that architecture. This isn't the forum to discuss the business
> issues, but the code does exist. The Java JDBC layer underway,
> but releasing it open source is for time being problematic.
>
> The advantage of this architecture is that an intermediate
> process is not required, providing a higher level of performance
> and security.
>
> >One thing in particular that I am wondering about is if the interserver
> >part has any reason for existence. Why not write a JDBC driver in java
> >that talks directly to Firebird core? I think this would involve
> >translating the C client into java. I haven't however figured out just
> >which files this c client consists of.
> >
>
> There are two issues, quite separate. One is Java/JNI plumbing.
> The other is mapping JDBC semantics into Firebird semantics. While
> not earth shattering, it is a significant piece of work.
>
>
>
> Jim Starkey
>
> To unsubscribe from this group, send an email to:
> IB-Architect-unsubscribe@onelist.com
>
>
>
>
>