Hi!
I don't mind using existing libraries but I would prefer to
have a 100% java driver. I would love to have it all in a
nice java package which I could debug without hassle.
I don't care about having a thin client either. I just
want to have a driver which I can rely on and
debug at will without setting endless compiler directives
and worrying about if an error is in code(gds stuff) that I can not fix.

Jim Starkey wrote in a previous post that
he built a basically functional "native code free" jdbc driver
on a sunday afternoon. I know that he knows this stuff
very well so maybe it'll take us a whole sunday. Just kidding.....
What if someone could give us some detailed and structured 3050 protocol info?

I have browsed through the code and the stuff behind
the various api calls is not greek although a bit unclear
to a c novice like myself and especially since I don't know much
about 3050-talk.

I would like to stay away from old code, JNI,
stringhandling and stuff that goes hand in hand with porting
c to different plattforms. 100% Java code speaking 3050
would really be a step forward and avoid future problems as I see it.

But it's a lot of work for a mere mortal like myself............

How about this?
a) If we can not get more info on 3050 -> java wrapper and gds-libraries
or
b) If we can get a 3050 documentation -> pure java

//OLAS


Ken Richard wrote:

> 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
>
>
> 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/