1. KInterbasDB also supports InterBase, but we don’t have necessary
expertise to maintain or even expand it’s IB support (both products
divert from each other more and more with every new version). So if KDB
would be maintained by Firebird Project, the IB support would be
eventually dropped, which I would consider as unfair to current KDB users.
2. KInterbasDB is currently implemented as C extension library wrapped
in a pile of Python code. This arrangement puts significant difficulties
on any developer that would like provide it on various OS (Firebird runs
on more than Windows and Linux) and Python platforms (for example
IronPython, PyPy). The future of this project seems to be in complete
rewrite in pure Python that talks directly to Firebird using the wire
protocol instead using the client library, i.e. in the same way like
JayBird type 4 driver or .NET Provider driver works. So while we’ll
maintain current KDB for some time, it will be eventually replaced with
completely new driver written from scratch, and although we’d like keep
it backward compatible, it’s not necessary to do that. Hence it’s
possible that next major version of KDB would be different product anyway.
In light of these arguments, we’re about to start a new subproject under
Firebird Project for Firebird Python driver. This driver will have new
name and it’s first version will be direct fork of KInterbasDB 3.2 (the
KInterbasDB is licensed under BSD-like license.) with our patches to
make it work with Firebird 2.1. We also have snapshots of KDB 3.3 that
adds significant new feature – support for multiple transactions in
single connection, which would make the basis for next version (it’s
stable, but not thoroughly tested). This would be the last major version
that would build on KDB codebase. This subproject would be lead by me
(i.e. I will take the responsibility for its maintenance, testing,
release, website etc.), but I suppose that more developers would join in
future.
best regards
Pavel Cisar
Firebird Project QA Team
« Hide it
