> What I do not understand, is why you are opposing current driver
> architecture?

I am not...I'm just ignorant...

> Main inconvinience is that you need to include some
> additional jars in classpath. JCA level does not introduce any
> overhead (only if you consider one additional method call as
> overhead).

My lack of knowledge shines through. I stand corrected!

> > summary: I don't want to critize, just convince of need. A slim
> > jdbc2-compliant type 4 driver for firebird would be useful in many
> > cases, both OSS (majority of jakarta/xml @ apache) and custom
> > shop.
>
> Maybe the key issue here is "slim". Our driver is not slim. In my
> opinion "slim" driver is only needed when you download classes over
> the network (JDBC in applet), but that's quite rare case nowadays. If
> you are on the server side, you do not really care how big is driver,
> only how fast is it. And in my opinion this is direction to go.

Well, since we want to potentially support many isolated programs running
within a single JVM (using Jakarta Avalon Phoenix) on potentially very small
devices (ie wearable computers in hospital setups) somewhere in the future,
"slim" is still an issue. We're still evaluating whether even basic JDBC is
an option in that case...

Nevertheless, KISS and other principles suggest the right granularity of
components is important. From looking at package structure, it seemed to me
there could be something important to gain in refactoring. Glad to have that
cleared up.

One thing I can see needs a little work is some docs to explain
interdependencies between JDBC and JCA drivers (and why this is not bad).

thought one: how do I volunteer to add some of that? (where do the patches
go?)
thought two: what kind of documentation system do you use/wish to use?
(should everything be in the javadoc??)

regards,

- Leo