Rick,

If this is terrifically boring to everyone else,
perhaps we should take it off list. OK, let me see if
I understand.


JDBC drivers are designed to run against a specific
database (Firebird, Oracle, Watcomm, Access, Postgres, etc.)
In theory, give or take such things as how databases
are addressed (i.e. connection strings) a Java program
should be able to connect to any conforming JDBC driver
and use it to access the database that driver was built
for.

OK so far?

To make the theory a bit more realistic, there's a
Java Naming and Directory Interface (JNDI) which is an
XML protocol that describes the connection to the database,
the driver name, and other important non-standards bits.
Assuming the Java program and the driver support JNDI,
the program can be blissfully unaware of what's on the
other end.

OK? Does Jaybird do JNDI?

Types. There were once upon a time, one imagines,
type 2, type 1, and perhaps type 0 drivers. The "typeness"
refers to the way the driver connects to the database code.
Ignoring (or being ignorant of types 0, 1, 2), let me echo
back that type 3 (Interclient) is an "impure" solution and
uses native methods to communicate. (sorry about the lousy
arrows)

Java program
|
V
JDBC driver database server
| ^
V |
native client side thing -> native server side thing


A type 4 driver is all Java right to the wire

Java program database server
| ^
V |
JayBird -> ?????


What does the communication on the server side for Jaybird?
Is JayBird speaking the same wire protocol as other remote
clients? Have we (finally) got some sort of rational way
of checking remote protocol versions?

More tomorrow.

One last question. Why do Java people refer to non-Java
code as "native"? Gives me the impression of men in white
suits and pith helmets, passing out Eurasian diseases.
Being a more botanical type, I think of native as "tough",
"well adapted to the locale", "xerotic", and "having small
boring flowers".


Regards,

Ann