At 01:32 AM 4/03/2003 +0000, you wrote:

>Hi,
>
> Can somebody explain me the real benefit of using C API to talk
>to FB over other components.

Do you mean "using direct API calls from a C program instead of using a
component interface layer" ?

Personally, as a Delphi programmer and user of IB Objects, I see no "real
benefit". It's the same API and both approaches use it.

However, C programmers will leap up and argue that, by programming client
or server layers directly with the API, you can build a thinner client
(implement only that which you need) and thus get better performance out of
your client or server application. I guess that, if a huge performance
benefit can be demonstrated, this really does matter for the server layer
of an n-tier system, or if you need to write clients to run on limited
resources like old PCs, PDEs, XBoxes...

My own belief is that an objective interface such as you have with Java,
Delphi, C++Builder, etc. is better from several aspects. One is that the
encapsulation of the API in classes means every application you write will
have a single level at which you add new support, tweak performance,
correct bugs, customise some special aspect of the interface, etc.,
etc. Another is code reusability. This really matters where the biggest
cost to the customer comes in the time programmers spend developing and
debugging and where multiple programmers and/or multiple applications are
involved. The benefit of reusability will be huge when the API changes and
grows.

An argument against a component solution might be cross-platform source
code compatibility. But even that's not as much of an issue as it has been
in the past, with cross-platform classes becoming more and more widely
available for ObjectPascal and C++, and Java beginning to win its
performance battles, and PHP, Python and DBI-Perl growing .

> Pls explain it seperately for client, server
> and network. I have to convince one of my client.

All client applications (including server-based application layers) use the
API. The API exists at one end of the wire, the server at the other
end. So, once the function structures pass the API threshold, there is
nothing that would make any difference on the network. The matter of
reducing network traffic is one of application architecture and economical
query design - an n-tier architecture will be faster than remote
client-to-server; and a greedy query is a greedy query, regardless of the
interface layer you choose.

Then, you have another option for n-tier, or where there is no
remote-client requirement at all - the embedded database type of
application. It doesn't access the API via external function calls at all,
but by running some special SQL syntax through a pre-compiler that
generates code to pass the function structures via an internal, macro-style
interface. For a C or Cobol programmer, this could be an option worth
exploring.

heLen