Hi all,

Some comments.

> Even Roman, who maintain the driver don't want to work on
> certain packages because he feels that is dangerous.

Some things to clarify.

First, I'm not the only person maintaining the driver. Maybe I
generate more traffic in the group, but till now three of us have
equal share of code maintainance (now we are four). We do have
different responsibilities, I was mostly concerned with JDBC
functionality to use driver at work with home-grown JDBC pool. David
is part of JBoss team, so he takes care of JCA and transaction
functionality. Alejandro did wire protocol implementation and this is
his responsibility.

Second, because of different responsibilities, I do not want to
change part of code that does not belong to me. Any change I make
that might influence other packages, are discussed between us or in
firebird-devel mailing list. This group is not development list, but
a support list for our driver.

> The real problem is that in an open source software like this
> Driver, if the people who develop and manage it don't go in the
> direction the users need, then another solution will appear and the
> people than want to collaborate in the development will select
> where they want to put it efforts. The solution that fulfil the
> community needs will grow and the other one die. That is open source
> democracy.

No problem with that. If somebody wants to start another
implementation of JDBC using even our code, I see no problem with
that as long as it sticks to the license.

> If a database driver focus on JCA and forget the correct
> implementation of JDBC, will be a candidate to death in the open
> source or in the commercial arena.

Sorry, I do not understand what is wrong with JCA. I'm open to
discussion, but I agree with David that everybody claims that JCA is
a big problem in a driver, but nobody says why. As I explained in one
of my previous postings, JCA adds no overhead to the driver
implementation. It requires driver developers be more careful when
working with connection and transactions and to consider JCA when
doing this or that. Issues we have are not issues like "this is not
possible, because JCA does not allow this". That's more issues of "I
have no time to implement this", "I have no idea how to implement
this with IB API".

> When I first test the firebird driver two weeks ago, I find
> that the driver fails and locks on too much tests to be used. During
> a later test I decide to look inside and finally I find myself
> patching it. Now the driver has a very improved JDBC support, but it
> is obvious that JDBC support is not considered a main focus on this
> driver until now and I don't know if it will be in the future.

JDBC _is_ the main focus of this driver. This _is_ JDBC driver, not
JCA reference implementation. And we really appreciate Blas work, as
a person that knows JDBC. It was maybe too ambitious for three of us
to start JDBC driver implementation without profound knowledge of
JDBC, but that's another question. But we expect community to help us
in areas we do not have big experience in. But community should also
belive in what we're saying, unless they can prove that we are wrong.
(Sorry if this sounds rude)

> The first one and more wise is try to refactor the code step by
> step and carefully to maintain everythink working during the
> process, and add the features the people need whenever it is
> possible. The only purpose of this refactor is to make the code
> cleaner and more understandable.
>
> ...(skipped)
>
> I hope those lines makes clear why I propose the refactoring.
> In past e-mails I explain exactly what I propose to do. It seems
> to me that what I propose is a really small change, too small to
> generate this mail activity.
>
> As I explain sometime in the past in this mailing list, I'm not
> user of Interbase nor the Driver, I'm only collaborating because
> I'm a software proffesional, I have deep knowledge of the JDBC api,
> and I need to fulfil my good actions quote for this year, but I
> can do it also in other software project or in Greenpeace.

I think the only reason that David, me, and probably, Alejandro, are
too conservative, is that we think we are really close to release of
first version. Those people who worked on driver more than year (I'm
with team less than a year) really want first to see it released, and
then focus on refactoring.

Would you start refactoring that should be done very carefully and
takes long time right before release date? No, you would first
release, and then make refactoring.

I think everybody agrees that refactoring should be done. Question
is "when?". My opinion is "after release". What parts of driver will
remain unchanged, and what parts will be changed is theme of another
thread, most likely in developer list, not here.

So, to summarize, I would say:

1. JDBC conformance is top priority issue.
2. Driver performance is also high priority issue.
3. Documentation is next issue.
4. Code quality is next issue.
5. JCA influences only how we implement, not what we implement.

Hope you will understand my point.

Best regards,
Roman Rokytskyy