From: Torsten W. <tor...@ne...> - 2000-08-19 10:15:12
|
Mark O'Donohue [mar...@op...] wrote: << The client java talks to interserver which is C code over a socket. The interserver calls the C api to get at the interbase server. If you replace interserver with a java version , you will still have to = talk to the C api, probably through JNI (Java's java -> c interface). >> If I were to use the C api, then yes, JNI would be the only means. It's = important to note that a Class 4 driver will be impossible with this = architecture. << Importantly it would still be calling the C api to do the database=20 things. >> Or we could access the Interbase server directly over socket 3050, = no?(which is why I started this thread) << But what you would get is some nice savings and simplicity in=20 writing the client/server java socket data exchage routines. java has=20 some nice things to do this but it works best if there is java on both=20 sides of the fence. If you have java on one side and C on the other=20 side then its a bit daggy. I assume that is what you are out to achieve. >> Right. This is my spare time project so I'm here for the fun of it. I don't consider hacking C code to be part of the fun, ya know ;-) But in earnest, I'm thinking about an architecture that combines Class 3 = and Class 4. If you have a need for a middleware (compression, = encryption or whatever) the InterClient/InterServer thing is ideal.=20 If you don't need this, a middleware makes little sense.=20 However, the first step would be an all-Java InterServer, yes.=20 << Again importantly it means that you still go through the C api layer. I can not see anyway arround that except rewriting interbase in java.>> Why no socket connection?=20 << PS: If you need any of the socket code, I've got examples the latest=20 stuff in the reflection proxy classes makes it really easy. =20 >> Are you talking about general Java socket code, or Interbase related = code? If it's the later I'm certainly interessted. Thanks, Torsten=00=00 |