Hi,

> The piece we need to complete the puzzle is a thin JDBC-2 compliant
> driver (preferable type 4) with minimal footprint. The current JDBC
> type 4 driver is sub-optimal in our case because it includes many
> feature we don't use (XA, JCA, pooling, log4j).
>
> It'd be nice if the current client-java were refactored to be
> modular, where there's a firebirdsql-jdbc2.jar (or whatever)
> providing nothing more than jdbc2.

I'm afraid this is not possible at present time. JCA functionality is
the bottom-most level of the driver, and I'm afraid that refactoring
would need to much efforts to make a clean separation between JCA and
JDBC.

What I do not understand, is why you are opposing current driver
architecture? 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). From the point of view of JDBC implementation, JCA classes
are just factories for low-level database connection handles,
transaction handles and statement handles.

> the one and only selling point for us is that it provides JDBC
> connectivity to firebird, and does so in a way we prefer to
> InterClient.

I agree. This is JDBC driver, not JCA reference implementation. But
JDBC compliance has nothing to do with JCA. We have not disabled any
feature except efficient autocommit for sake of JCA compatibility.
Autocommit case is very specific and personally I have no idea how to
solve it at all.

> I think there's quite a few "buyers" that like it for other
> reasons.

Well, the one clear thing is that InterBase supports native 2PC (two-
phase commit), standard JDBC is 1PC, XA is 2PC. So, in case of
transaction management, JCA fits better. You always can map 2PC into
1PC by merging prepare and commit phases. Reverse mapping is not so
easy (BTW, does anybody know how JCA wrappers solve this issue?).

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

Best regards,
Roman Rokytskyy