Subject | Re: C API Upgrade? |
---|---|
Author | gerryw@compvia.com |
Post date | 2008-02-01T05:30:10Z |
Hi,
Okay...
I always try to avoid invoking the name of another product/project in an
effort to avoid
the inevitable "better mouse trap" discussion. This usually results in
just burying the
original topic, but I'll take a chance.
I was regarding the Firebird C API (libfbclient.so on linux) as being at
the same level or
equivalent to the PostgreSQL C API (libpq.so on linux). These interfaces
to me, represent
the foundation interface or protocol reference code offered up by the
particular database.
They can be both a protocol reference and serve as the foundation for
higher level interfaces.
These interfaces also have a tendency to be written in the same language
as the database
engine itself.
What I'm suggesting is simply that with a little effort and careful
design, the C API could be
made much more useable as a C API in it's own right. The new functions
would have no
impact on the existing interface. The other major databases all provide a
more useable
C API that is maintained as part of the official code base. I would like
to see Firebird do the
same thing.
I'm not suggesting this for my own benefit. I'm sure my current project
will be completed long
before these changes would actually see the light of day. I'm thinking of
those who may come
after me. I wasn't swayed in my efforts, but they may well be. For
example, if someone was
writing a replication interface or a gateway to another database, I would
want them to use
the C API. I know I certainly would. Anyway, I can't understand what would
be lost by making
the C API more useable. If it encouraged even one or two additional
developers to make a
contribution, it would be well worth it. This is particularly true when
you consider that the effort
required to add these new functions would be roughly equivalent to what is
necessary to use
the C API in it's current form.
Please consider the following scenario. Let's say I had a new idea or
innovative approach
to database replication. I would want to implement a prototype of my
replication engine
design. One of my first steps would be to take a look at the C API
interfaces for all of the major
databases. The current Firebird C API would be eliminated in the first
pass. When implementation
time came, it would be last on the list. This concerns me, because I'm
almost sure it has happened
before.
Thanks,
-G
Gerry Weaver
Compvia Corp.
(800) 257-6304
[Non-text portions of this message have been removed]
Okay...
I always try to avoid invoking the name of another product/project in an
effort to avoid
the inevitable "better mouse trap" discussion. This usually results in
just burying the
original topic, but I'll take a chance.
I was regarding the Firebird C API (libfbclient.so on linux) as being at
the same level or
equivalent to the PostgreSQL C API (libpq.so on linux). These interfaces
to me, represent
the foundation interface or protocol reference code offered up by the
particular database.
They can be both a protocol reference and serve as the foundation for
higher level interfaces.
These interfaces also have a tendency to be written in the same language
as the database
engine itself.
What I'm suggesting is simply that with a little effort and careful
design, the C API could be
made much more useable as a C API in it's own right. The new functions
would have no
impact on the existing interface. The other major databases all provide a
more useable
C API that is maintained as part of the official code base. I would like
to see Firebird do the
same thing.
I'm not suggesting this for my own benefit. I'm sure my current project
will be completed long
before these changes would actually see the light of day. I'm thinking of
those who may come
after me. I wasn't swayed in my efforts, but they may well be. For
example, if someone was
writing a replication interface or a gateway to another database, I would
want them to use
the C API. I know I certainly would. Anyway, I can't understand what would
be lost by making
the C API more useable. If it encouraged even one or two additional
developers to make a
contribution, it would be well worth it. This is particularly true when
you consider that the effort
required to add these new functions would be roughly equivalent to what is
necessary to use
the C API in it's current form.
Please consider the following scenario. Let's say I had a new idea or
innovative approach
to database replication. I would want to implement a prototype of my
replication engine
design. One of my first steps would be to take a look at the C API
interfaces for all of the major
databases. The current Firebird C API would be eliminated in the first
pass. When implementation
time came, it would be last on the list. This concerns me, because I'm
almost sure it has happened
before.
Thanks,
-G
Gerry Weaver
Compvia Corp.
(800) 257-6304
[Non-text portions of this message have been removed]