Oops..wrong button. Let me try again.

I do believe that this is the best approach, even just for the purpose of
getting development started. The JDBC semantics of the upper layers of the
driver are going to be the same no matter what mechanism is used to talk to
the server. I believe that the JNI stuff will be a lot easier to implement
and that we can get started there. I think we start by defining the
internal interface betweent the JDBC semantics and the valves. Then some we
can divide up the work. Some can start working on the JDBC, some can start
working on a JNI-GDS valve and some can start working on a pure 3050/XDR
protocol valve.

The valve classes are implemented according to firebird/interbase semantics
and the jdbc classes are implemented according to jdbc semantics.



-----Original Message-----
From: news@... [mailto:news@...]On Behalf Of Mark
O'Donohue
Sent: Thursday, April 26, 2001 10:30 AM
To: IB-Java@yahoogroups.com
Subject: Re: [IB-Java] Re: JDBC Development

<SNIP>

Application
-----
DBXXXConnectionInterface
-----
with three seperate potential implementations (names for examples only)
(DBXXXRemoteConnection,
DBXXXLocalConnection,
DBXXXInterserverConnection

This in the jdbc client I would see acting much the same as Y-Value
currenly
does in the C client.

The "LocalConnection" type 2 guy since it goes through the existing C sql
interface would additionally go through the C Y-Value layer to determine if
it was really local or connecitng remotely.

<SNIP>