>
> Message: 6
> Date: Tue, 20 Feb 2001 15:53:27 -0500
> From: Jim Starkey <jas@...>
> Subject: RE: Architecture of interclient
>
> At 03:41 PM 2/20/01 -0500, Ken Richard wrote:
>
>> Unfortunately, some people may like the zero-client-install of
>> interclient/interserver.
>>
>
> Then they will be happy to accept the performance/security
> penalty.
>

From my experience a 100% java client is the best solution.

Actually I would say that not having a 100% java client solution (even
if other options are available) misses the point of using java.

An entirely java client reduces problems of install/transporting across
various client platforms to zero. Running on a mac client for instance
only then requires the JVM (same for Solaris, Linux, FreeBSD, etc).
I've used this approach with Oracle and with MSSQL... and FB/IB using
interclient. Problems I've previously had with say ODBC client
libraries just go away.

The performance penalty seems to be mainly in the extra layering (in
interclient anyway). That being the way type 3 drivers are. And it
would require either a rewrite of the most of the "interserver" c++
layer in java and place it on the client side, or a deeper integration
of interserver into the db engine itself.

I don't see the java layer adding any additional security problems,

Of course when the client directly accesses a local database file,
rather than talking to a server over a socket, it's a different story.
And a binding which directly calls the C routines through a JNI call
would be in order. The format of the JDBC connect URL would probably
indicate which connect method should be used.

Cheers

Mark


--
Your database needs YOU!
http://firebird.sourceforge.net