Ann,

> Then I guess the question is: "does Jaybird publish JNDI
> descriptions of itself, or must the user intuit the values
> and create the descriptions?"

JayBird has standard JNDI descriptor for JCA deployment. However,
person who deploys it, must configure it. Usually it is done using
nice GUI shipped with application server. All possible parameters are
displayed in that GUI.

If it is not deployed through configuration, it must be done by
hands. In Java it looks like this:

// create javax.sql.DataSource implementation
FBWrappingDataSource dataSource = new FBWrappingDataSource();

// set connection parameters
dataSource.setDatabaseName
("localhost/3050:c:/database/employee.gdb");
dataSource.setDescription ("An example database of employees");
dataSource.setUser("sysdba");
dataSource.setPassword("masterkey");

// create JNDI context
javax.naming.InitialContext ctx = new javax.naming.InitialContext();

// bind data source to specific name
ctx.bind("jdbc/myDataSource", dataSource);

This code is executed once. And now this data source can be found
using following code:

javax.naming.InitialContext ctx = new javax.naming.InitialContext();
DataSource dataSource = (DataSource)ctx.lookup("jdbc/myDataSource");

However, binding data source by hands is rarely needed, because
almost every application server and Java web server (Tomcat, Resin,
etc.) has possibility to specify this in their configuration. As far
as I know we have example configurations for them in our FAQ.

> >Assuming that the SQL commands you use work with both.
>
> Which is unlikely. No, Ann, don't start on standards. It
> just gets you upset and antagonizes everyone else.

Actually the situation is not so bad. I am able to switch between
different database servers (JDataStore, Firebird, PostgreSQL, Oracle)
without big problems. All client-side SQL is stored in resource
files, and if the number of input params and output params remains
the same, changing resource file does the trick. JDBC also specifies
some escaped syntax for parts of SQL that differ greatly between
servers.

For example, in JDBC SQL stored procedure call looks like this:

{call my_proc(?, ?, ...)}

And later you define, that param 1-3 are input params, and param 4-5
are output params. Then we form correct SQL and execute it.

> Traditionally the wire protocol has been "private" meaning that
> only the people who actually developed the client and server ends
> needed to know what's in it. That allows for a great deal more
> flexibility than a published API where every change must be upward
> compatible etc. It also leads requiring that the client and server
> be upgraded at the same time, which, to my way of thinking is a
> bad thing.

So, we are the team that develops client and server ends. :)

BTW, .Net driver is developed the same way. It talks wire protocol
over the network connection.

> What I meant is precisely a handshake thing where the client says
> "I speak protocols 2.1, 2.2, 3, 3.04, & 7". The server says "I
> speak protocols 3.2, 4, 5, & 7". We agree on 7 and off we go.
> However, in the past, the protocols have not been rigorously
> labeled, so there are sometimes several variants that claim
> be the same. What I'm advocating is strict adherence to protocol
> versioning and possibly documenting the differences between
> versions.

As far as I know, we do not have any document where the wire protocol
is defined. I would start with it. Then we can move to the protocol
versioning.

Best regards,
Roman Rokytskyy