The easiest approach is to take an existing c++ API and write a java
wrapper. I looked into the IBPP api, but they don't do any boundry checking
when processing strings. Another possibility c++ api behind the OdbcJdbc
driver, but we know that is not available. Another idea would be to rip out
the network stuff from the middle of interclient/interserver and put in a
JNI level.

I think that the 3050 would be a lot more work because of the protocol
crunshing required. Personally, I am looking for a high performance driver
that can be used to access the database from a server application. I don't
care about 100% java client and can live with the requirement to have gds
installed.

If there is information about the 3050 protocol, I would be glad to take a
look at it - but I have not been able to find any documentation and getting
the interbase server to build (on win32 anyway) is a real pain.


-----Original Message-----
From: Ola Samuelson [mailto:ola@...]
Sent: Wednesday, April 18, 2001 10:22 AM
To: IB-Java@yahoogroups.com
Subject: Re: [IB-Java] Re: Dying connections with interclient


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