At 12:14 PM 1/02/2008, gerryw@... wrote:

>Hi,
>
>I must need to work on my communication skills. I apologize if I have
>created any confusion about the intent of my post. My post is directed toward the developer(s) who would have written the interface for Delphi and the like.

Following this thread, one thing that appears to me is confusion between what we (Firebird people) and you (C programmer from the outside world) regard as "the Firebird API". I don't think this confusion is helped by the fact that the MySQL and PG communities use terms like "Java API", "PHP API" and so on. We call this level of layering "driver". To us, the API is that set of bits and pieces that are exposed to the world by the client library as a mixed bag of formal C language functions and structures.

>My example functions were not intended to be a detailed design. They were
>just an example of what might be possible. I am still working on my abstraction. I have not had an opportunity to work through all of the issues yet.

It might be a lot easier when you figure out what you're really aiming for. So far, it appears to me that what you really want to arrive at is what we think of as "a driver" - a layer that wraps related API calls into higher-level packages of reusable code that you can compile into any C or C++ code statically or dynamically, for effecting requests simply and consistently. Or something else?

>There are some of us who work exclusively in C/C++. We are typically the folks who code the interfaces like the one you mentioned.

There are some of us who work exclusively in C++ (which doesn't include me, incidentally). Some folk who typically do coded the IBPP interface for C++. There are some of us who work exclusively in ObjectPascal. Quite a lot of folk have coded ObjectPascal interfaces, some very lean and mean, others very richly featured. I use one of those. Some folk have coded Java interfaces, most notably our own Jaybird interface, which bends the client API to fit external standards. Similarly too, our .NET Provider, our (and others') ODBC drivers, and other access layers that have been developed for Python, PHP, Ruby and so on, that are confined to standards one way or another.

All of these are client-language-specific "data access layers" that load (or, in the case of Jaybird, reimplement) the Firebird API (the dynamic client library) and interpret its exposed functions in language-specific ways and often in ways that are blind to vendor-specific idiosyncrasies. Note here the emphasis on "client". All this language-specific wrapping wraps the CLIENT API.

>I remember when a lot of the initial Firebird/Interbase bindings/APIs first appeared.

I remember the day that humans first walked on the moon and, yes, I also remember when Borland figured out that the demand for reusable code wasn't going to go away and gave us the BDE and InterClient. Aaaargh!!!! But that was a VERY long time ago. [And, yeah, Borland never did get it right with their Java client until they day they binned it and did Something-Totally-Different-But-Lets-Not-Go-There. :-| ]

>Most of them were pretty buggy to start with. It is exactly that problem that I'm trying to address.

Open source is a lot about assuming that the wheel has already been invented and trusting that "round" is a good enough shape for it. You could well address your problem by studying what others have done with the raw API since the birth of the BDE. The sources for IBPP, Jaybird and the .NET Provider are readily available. ObjectPascal translations of ibase.h and iberror.h are available. Likewise the interface libraries for dbi::interbase, php and others. And, contrary to rumour, Vulcan isn't dead - you can certainly grab its client code to look at what "jeams" set out to do with the legacy API.

Helen