On Fri, Dec 02, 2011 at 03:01:37PM +0100, Pavel Cisar wrote:

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

Well my vote is to create new git fork for pyfirebirdsql
and then to merge your work there and push it back in a branch
It's a lot easier to develop on github and i guess anyone can join and improve it after first
commits are online

>
> best regards
> Pavel Cisar
> IBPhoenix
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>