Hi,

I like it,

I have the classes implementing the jdbc interfaces almost done and
compiling ( everything is a no-op). I have to think about class
inheritance /interface inheritance a bit, and incorporate the JCA classes.

I have used the naming convention like this:

java.sql.Array interface >> org.firebirdsql.jdbc.FBArray


Is this OK with everyone? If no complaints, and I get the classes done, I
will commit them tomorrow or saturday.

I'm also setting up a build/ lib/ etc build directory structure with an ant
build script, and the jars for the interfaces and ant and junit in
appropriate places. That way if you have jdk you can download everything
you need at once.

I have no experience with jni, would it be faster to concentrate everyone
on the java-gds? Do we even have someone who wants to work on the jni?

I plan to work on implementing the JDBC stuff, especially the XA/JCA since
so far I seem to be the main person wanting it.

Thanks
David Jencks

On 2001.04.26 12:09:37 -0400 alberola@... wrote:
> Hello,
>
> I also think that having a GDS interface to be implemented
> with a Java-GDS and a JNI-GDS is the best approach.
>
> I am going to define this GDS interface and post it
> to this list in a day or two for your review.
>
> I think that the teams needed would be:
> 1. A JDBC team that will implement the JDBC semantic
> using the GDS interface.
> 2. A Java-GDS implementation team (at this moment I am
> in this team and this implementation is a work in
> progress) :-)
> 3. A JNI-GDS implementation team.
>
> Any ideas ?
>
> Bye.
>
> Alejandro Alberola
>
>
> --- In IB-Java@y..., "Ken Richard" <kenr@a...> wrote:
> > 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@n... [mailto:news@n...]On Behalf Of Mark
> > O'Donohue
> > Sent: Thursday, April 26, 2001 10:30 AM
> > To: IB-Java@y...
> > 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>
>
>
> To unsubscribe from this group, send an email to:
> IB-Java-unsubscribe@egroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>
>