Subject Re: [firebird-php] PHP Driver status
Author masotti
Hi Pierre,

Pierre Joye ha scritto:
> The extension is now called ext/interbase and will remain like that
> for a while. The other extension is pdo_firebird. The problem is to
> keep BC for ext/interbase.
Ok. Now I see you call it ext/interbase independent from target OS. Only
one source repository for all
The other is ext/pdo_firebird. Same (or similar) targets.
>> Second step: you need to "get" php_interbase.dll for VC6 and VC9. This
>> is less clear to me: do you mean that you are searching a developer to
>> maintain all that in saecula saeculorum or only a development system to
>> compile and have libraries built?
> I need working firebird libraries, alternatively interbase as well. It
> is unclear for me what is necessary to have both working, even as two
> extensions (like my oracle example).
"working firebird libraries". Mmmhh (thinking). "what is necessary to
have both working". Mmmmmhhhh (deeper thinking).
Which of these things you have not clear, and/or you don't have (or I
missed completely your needs)?
1) ext/interbase sources
2) VC development system
3) firebird's include files for user program/libraries compilation
4) firebird client libraries (fblient.dll)
5) code samples to firebird API
6) other / not arrived / ?

>> What is needed to be "a maintainer"?
> A maintainer maintain an extension, he fixes bugs, update libs (or
> help the windows guys to build them), etc.

>> 1) A perfect library driver, AFAIK, has no need of test, right? So test
>> are implemented when a bug is found to block regressions IMVHHO.
> Wrong, tests are needed to be sure that a patch or change does not
> break more things than it fixes.
And verify php lib/client/server compatibility... :(
>> 2) What is a "minimal" test suite to start from? Firebird server's test
>> suite is big, but has another goal. Starting from SQLServer or Oracle
>> and adapt may be a solution but for what?
> See pdo_mysql, mysqli, etc. they are well covered :)
AFAIR transaction management in mysql isn't the best approach, but web
developers often don't care: anyway it's one of the stronger point in FB
so I thought Oracle like an example.

> it is useful to allow us to fix bugs without breaking every single
> Firebird app out there :)
Agree. :)
>> ... skip ...
>> Interbase lib: .\ext\interbase\ibase\php_interbase.dll
>> Firebird lib: .\ext\interbase\fbird\php_interbase.dll
>> Maybe a good starting point. Being prepared, in the future, to have
>> distinct .\ext source dirs.
> Not exactly, what I mean is that the same extension (ext/interbase)
> can end in php_interbase.dll and php_firebird.dll using the same
> source code but linking against different libraries, gds32.dll and
> fbclient.dll respectively.
Oh! Even better!
> My problem is to build fbclient.dll using VC6 and VC9, to know which
> version I should use, with which options, is it backward compatible,
> etc...
Let's stop here for a moment.
Seems you need knowledge to build all versions of fbclient.dll to link
ext/interbase and ext/pdo_firebird in all flavours. Am I right?
AFAIK firebird client libraries are prebuilt for windows distribution
(problem about VC9 runtime libs AFAIR is solved for VISTA, Server and
XP) and there were a discussion about to prepare a downloadable version
with only client libraries. I've just chcked at
but there's nothing as client lib download, so only choice is download
standard .exe (not pdb nor embedded versions) and install only client
libs (it is an option during installation) or downloading .zip and
manually extracting what you need (beware: maybe not simple and Vista
may don't like it).
Note that for Win64 there is only 2.1.1 and 2.5 Alpha
As a note aside, for Linux, Mac and some unixes, on Intel, FB libs can
be built from packages. For specific processor (like Sparc, PA-Risc,
Itanium, AS/400 or.... ) don't know.
Going further, another novel is which client lib version with which
server version compatibility. Please: this can be material for tests,
but matching both versions is the best; this mean that to test Win64
client you need a 2.1.1 server (on any 32bit or 64bit OS).
Going back to libraries, every windows user installing firebird
client/server or only client don't builds libs because it's intended
not a necessary step to have to do.
Every version of Firebird comes with his sources include files needed to
interface client libraries. In Linux, you cannot build ext/interbase
without client libraries AND relative sources installed. At worst, in
windows this means that for every release of firebird client API (1.5,
2.0, 2.1 and in near future 2.5) a different ext/interbase release.
Often this is not the case, because interface tend to be compatible /
identical, but this is a question I must turn to Firebird's
maintainers/developers to be 100% sure.
In general, someone other can be more precise, point releases of a major
version (e.g. 1.5.0, 1.5.1, ... to 1.5.5) are only bug fixing:
interfaces don't changes. Intermediate releases (e.g. 1.5.*, 2.0.* and
2.1.*) imply a different ODS (on disk structure) of database, meaning a
different interface with API expanded to maintain new features. Major
releases imply a different step in architecture and ODS.
Backward/upward compatibility means an excel paper big as my desk
allmost filled with "true".
This answer to some of your questions?

> After 5.3.x (be 5.4.x or 6.x), we can imagine a dedicated extension
> for firebird only. I would suggest to share the work done in
> pdo_firebird. You can even begin the work right now in pecl and ask
> for inclusion once you are ready (see below).
>> Don't sure whay you mean with pecl extensions. Do you mean that is
>> possible to start a "new" firebird library project in pecl directly?
> Yes, that sounds like the best approach to me. Doing so will minimize
> the breakages in the current extension and let you work without the
> pressure of a php release.
Ok. Another fixed point. I'll need to find more information about what
is involved in this type of development, but I'll search in internet.
See you later, now I've under pressure... ;)