Hello All,

I searched the list archives in various ways, but did not find anything
like this. I apologize if this issue has been raised before.

I recently embarked on a project to write my own database abstraction
library. I have used a variety of different APIs over the years, but still

seemed to be writing the same code over and over again. It has been my
wish for some time now to get the chance to write something that worked
better for me. Anyway, I set out to have the library support all of the
major open source databases. All went fairly smoothly until I encountered
the Firebird C API. Wow... I've been a programmer for over 20 years and I
had to sit in awe of the ridiculous and needless complexity of this API.
Don't get me wrong. I love Firebird. I have used it for a long time on
many projects. I'm not trying to criticize the good folks that maintain
the code either. However, I strongly believe that this issue should be
addressed. I now understand why it's takes various applications so long to

support Firebird and some not at all. I also see how this could be a major

stumbling block for potential users/developers. There is just a tremendous

liability in implementing an application on top of this API and getting it

stable / bug free. I realize that there is probably a ton of code that
depends on the current API spec, but it seems like there could be a
gradual move in the direction of something better without hurting the
existing code. I also realize that there are several other projects that
aim to provide wrappers for the C API, but this is not really the same as
a good C API supported and maintained by the core Firebird team. I would
like to propose the possibility of the addition of a set of higher level
functions to the existing API. These added functions would serve to hide
the dpb and cook the SQLDA data into some thing more useable and less
error prone as a start. Is anyone interested in something like this? I
think it would go a long way to making the use of Firebird an easier
decision for developers. I would be more than willing to participate.

Thanks for your time,
-G








[Non-text portions of this message have been removed]