To all,

I have not contributed code yet, but would like to at some point. I am
learning about the C API at the moment at the same time I am creating a
C++ wrapper like IBPP but designed like a JDBC driver. So there are
classes such as Connection, Statement, PreparedStatement and ResultSet.
So far so good, but it's mostly for my current needs, so will require
lots of work to be as useful as IBPP to others. However Java people
using a JDBC driver and then needing to use C++ will love it.

While most of my experience is in Java, I need to learn C/C++ for some
internal apps that I am developing. I am not using Java due to
deployment time of the app. I do not want to have to install JRE on each
machine my apps will run on. Plus I prefer the speed of C/C++ over Java.
Not to mention using less system resources in the process, if I
design/code the apps properly.

To the point, I think migrating to lgpl is better than the current
licensing scheme. I am still trying to understand all the different
licenses out there. From my understanding so far, if any part of a gpl
app is using a license that is not gpl compatible it makes the whole app
non gpl compatible. According to

http://www.gnu.org/licenses/license-list.html

So the current license scheme really screws things up. So I would
recommend go with one or the other and do not mix them. At the same time
I am not to sure how many people will be building gpl compatible apps
with the driver. So it may be a mood issue, but from a legal standpoint
it really should be one or the other. They are two different licenses
mpl/lgpl. MPL is not GPL compatible.

Now on the release front, I would definitely stick with RC1 if
anything. I feel the driver needs a bit more work before going to the
final release stage with a 1.0 version number or something.

There are still some quirks here and there, one of which I still need
to make a sample app to demonstrate. I am getting ready to go on
vacation and will see if I have some spare time to slap a test app
together. But I mentioned the problem and the fix a while back, but the
CVS code does not seem to reflect this change. The problem I ran into
was an uncatchable exception being thrown when selecting a empty blob
column/row. The past threads with the details are in the list archive.

Anyway outside of the few quirks here and there, the biggest thing I
would like to see addressed in some manor is the speed of the driver.
The current driver seems a bit sluggish compared to InterClient. I have
had some clients complain, and ask why I switched drivers.

For performance reasons and some others like the blob issue I should
have stuck with InterClient. Although in doing so I would not be helping
the development on the new JCA-JDBC driver. While I have not contributed
code, I feel feedback and testing in the real world is almost as
important. So my dropping InterClient for the JCA-JDBC driver was to
help out in what ever way I can. So the JCA-JDBC driver can be all it
can be.

If there is anything I can do/contribute, testing wise or anything else
I am happy to like others, as I have time to. When I build my general
understanding of working with FB on the low level I do plan to join the
project and contribute code if I can. By project I mean the JCA-JDBC
project, not so much the Firebird project. That's still out of my
league.

That's my four cents. :)

--
Sincerely,
William L. Thomson Jr.
Support Group
Obsidian-Studios Inc.
439 Amber Way
Petaluma, Ca. 94952
Phone 707.766.9509
Fax 707.766.8989
http://www.obsidian-studios.com