Hi,
I may be all wrong about this, if so please let me know.

My impression is that gds.so is the c client library and that it is what
talks to firebird on port 3050. It is intended to be linked into your
client program. Interserver exists because Borland didn't want to replace
gds.so with java code that talks to port 3050, but they did want to have a
pure java driver. So they wrote a C program that talks to java on one end
and links to gds.so on the other...voila, interserver. The two ways to
eliminate the extra layer are:

1. Give up on pure java, write jni code that talks locally to gds.so

2. Rewrite the functionality of gds.so in java so we get a pure java
driver.

Jim was originally proposing (1) using his c++ odbc driver, but as I
understand it has decided (2) is a better solution, and apparently easy to
implement for Netfrastructure. I hope it's just as easy for firebird!

There were quite a few messages on this subject near the end of February.
You might look in the IB-Architect archives for messages from Jim and
myself on subject Architecture of interclient, from 2/20 to 2/24.

Thanks
David Jencks

On 2001.04.18 10:22:16 -0400 Ola Samuelson wrote:
> Hi!
> I was thinkin ......
> There is a starting point as far as I understand it.
> It's gds32.dll on windows and gds shared object on linux.
>
> Using these as starting point saves us some guesswork since
> the API calls are documented. I am looking at the API guide right
> now together with code like IB_connection.cpp from the cvs.
> This code use standard API calls to do the job.
>
> So this is one approach, BUT we would like to loose
> the gds api altogether and THAT requires some more info I think.
>
> On the other hand, eliminating interserver and just using a new
> "interclient"
> that speaks to 3050 directly may be good enough.
>
> One source of errors less.
>
> Speaking "3050" using the api guide looks pretty straight forward
> and like a "normal" development task.
>
> I don't know........ideas?
>
> //OLAS
>
> Ken Richard wrote:
>
> > I started poking around at a driver that uses GDS32.DLL and it didn't
> look
> > too bad until I got to the SQLDA stuff. I was going to look at the
> > possibility of using port 3050, but I am having trouble getting
> interbase to
> > compile so I can use the debugger to figure out how the GDS stuff
> works. I
> > couldn't find any documentation on the protocol other than the code.
> >
> > -----Original Message-----
> > From: David Jencks [mailto:davidjencks@...]
> > Sent: Wednesday, April 18, 2001 9:00 AM
> > To: IB-Java@yahoogroups.com
> > Subject: Re: [IB-Java] Re: Dying connections with interclient
> >
> > Hi,
> > I think you start by figuring out the Firebird C client to server
> > communication protocol and writing a java client using it. You can
> then
> > figure out how to make the jdbc calls map to Firebird api calls (this
> is
> > much of what interserver does). Then you can figure out a way to
> handle
> > the DatabaseMetaData stuff (this is most of the rest of what
> interserver
> > does).
> >
> > ...
> >
> >
> > 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/
>
>
>
> 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/
>
>
>
>