At 10:00 AM 2/22/01 +1100, Mark O'Donohue wrote:

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

The user written Java code is, as it should be, isolated from
the implementation. Casual database use probably doesn't care
about performance, and the security hit of passing all passwords
and data through an extra server probably isn't that bad. If
you have ever looked at the implementation of the lower layers
of Java communication code, take a look. It's not pretty and
it's not fast.

But if somebody wants to use Java in a production environment,
the issues aren't so simple. An intermediate server doubles
the network traffic, adds latency, and (unkind generalization on
Borland's communication implementations omitted).

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

We're not talking about ODBC. We talking about a JNI solution to
map JDBC semantics directly on the Firebird API. And maybe supplanting
the legacy API in the process.

Installation should involve sticking two additional platform specific
dynamic libraries in a system directory (a JNI native library and the
Firebird/jdbc layer). No other configuration should be necessary.

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

Is you argument that it has to be slow because other drivers are
slow?

I don't understand what any additional code needs to be written
in Java (not that I have any objection to Java code).

I'm not suggestion anyone rewrite, re-architecture, or
re-implement interserver. I'm merely suggesting that we
junk it.

But I don't have an answer for the MAC. Never did. I particularly
dislike the interaction of the MAC press and IT departments.
If you make the MAC version of a product look like the PC version,
the MAC press skewers you. If you make the MAC version look like
a MAC product, the IT guys hate you. So putting a product on
a platform where, regardless of what you do, everyone is going
to hate you is a loose. That's why Interbase never went there.
Besides, if balance the development cost against the tiny number
MAC-ites wanting a database API, it's cheaper to buy them real
computers. </rant>

Jim Starkey