Hi all,

Those who attended my "Python drivers" session at conference in
Luxembourg already know that last two months I have worked on another
Python driver for Firebird (codename fdb). It was just an experiment how
far I could go in short time with another approach to implementation,
not real attempt to replace both existing drivers (KInterbasDB and
firebirdsql). However, it went so well, that we have a real chance to
get out a truly universal pure Python driver for Firebird next year.
Here are details...

The *fdb* driver is based on my old experiments (back in 2009) with
ctypes interface to Firebird. Back then it ended with ibase.py interface
and very basic connection and transaction classes, and ability to make a
connection and start a transaction. Over last month I was able to
implement full DB API 2.0 Spec + some extra.

- Connection, including drop and create database
- Transaction, incl. multiple transaction per connection, transaction
parameters, savepoints and retaining.
- Cursor. Fully supports materialized BLOBs, input parameters (incl.
BLOBs), should handle dialect 1 gracefully (but it wasn't thoroughly
tested), has row mappings and iterator protocol support built-in,
automatic unicode/connection charset conversions.
- Services. All what KInterbasDB 3.3.0 supports (i.e. all except TRACE).

What is missing:

- Prepared Statements (some work done, but unfinished).
- db_info API calls
- Support for streamed BLOBs
- Support for Firebird Events
- Distributed transactions
- Trace API Service support
- Support for Firebird arrays

I'm going to finish the prepared statements and db_info call, add some
basic documentation and import sources to Firebird Projects Subversion
repository this month (hopefully before Christmas). Next I'd like adapt
KInterbasDB unit test for new driver. I wrote several unit tests myself
for new driver, but using KDB ones would help us to set a reference for
next development as the primary goal is to make the driver as much
compatible with KInterbasDB as possible, so existing applications
(specifically Firebird QA tool-chain) could be easily ported to new one.

At this stage (sometime in January) we should have fully functional beta
driver suitable for 95% of tasks based on ctypes (FB client library). As
both ctypes and wire protocol interfaces have their distinct advantages
and disadvantages, I'd like propose to unify *fdb* and *firebirdsql*
into single, official Firebird driver for Python, housed at Firebird
Project (under name firebirdsql). The idea is that at that point (end of
January) we should have enough functionality and unit tests implemented
to start work on *inner* interface to talk with Firebird engine, that
would allow us to have single higher level core with two "communication"
implementations, one based on ctypes, and one based on wire protocol
(and eventually third one using new object interface provided by FB 3.0,
btw first alpha of 3.0 should be released in Q2/2012).

In parallel with these unification works, I will continue to implement
the remaining features, namely streamed BLOBs, events and distributed
transactions. If Hajime would agree to join our efforts and merge the
drivers, we should also easily get (and keep) support for Python
2.x/3.x, as his primary development platform is Python 3 and mine is
still 2 (2.6 to be precise).

So, that's the current situation and plans for future. Any comments are
welcome...

best regards
Pavel Cisar
IBPhoenix