Redesign and reimplement the API is in my plans, and in the last
messages on this list I proposed (and have half implemented) a C++ (but
C compatible) API for external procedures.

The requirements IMO for a new API is:
- use the same public API in engine internal code
- since now, don't introduce any major set of public functions (for
example: external procedures, external datasets, providers) like the
current API

But I don't think the ISC API is a problem for C. It's really not easy
to use directly, like any C API.

What I still don't understand is why parameter names is not used in the
prototypes, like in many internal FB headers, making things worse. Maybe
old compilers complains.


Adriano


gerryw@... wrote:

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