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

Pierre Joye ha scritto:
> No worry, I am relax and here to find solutions. I only avoid any kind
> of FUDs or discussions that we already had (especially those bringing
> bringing nothing).
>
Ok. Let's clarify the sentences we are not understanding each other.
> My only goal here are:
>
> - get the client libraries required for php 5.x and 6.x available as
> soon as possible, for VC6 and VC9
>
First step: as I understand here you mean windows version of
php_interbase.dll. Actually, if this is the case, let's continue to call
it php_interbase.dll and not php_firebird.dll, whether or not this can
give stomach ache to me. Don't worry. :)
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?
> - Get the current firebird dirvers some love from the people who actually use it
>
I think I have understood, but not sure. We are not a lot of people,
despite number of installed servers, and there is a lot to do that
majority of us do in spare time.
> Our main issues are that we ran in circles every time we began a
> discussion to organize the future of firebird in PHP. Some says that
> everything works well but a couple of bugs, but the facts are:
>
> - the firebird/interbase extension has no maintainer
>
This maintainer has to be a component of the Firebird project or of the
PHP project or both (or none of the previous)?
What is needed to be "a maintainer"?
> - they have almost no test
>

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.
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?
AFAIU testing without a goal isn't even an useful exercise.
> - there is no clients library available to be used for the windows release(s)
>
Ok, if we are speaking again about php_interbase.dll see before. A step
at the time.

> See the PHP Internals archive (available via http://www.php.net search
> box, search for "firebird lester" should give you all discussions).
>
Ok, more or less now I have a vague idea of the background. Better than
nothing.
> Let us try to summarize the problem.
>
> Do I understand correctly if I say:
>
> - We need two separate extensions, linked against two different
> libraries/clients:
> 1. Firebird clients
> 2. Interbase clients
>
Yes: Firebird six years ago implemented a new client library to be
linked to, fbclient.dll, while Interbase use continue using old name
gds32.dll
> They can't be loaded simultaneously (obviously as clients API will
> conflict). Ideally we would have to change/update/improve the API
> (can't be done in 5.3.0).
>
Yes. Actually php_interbase.dll links gds32.dll and we need to remove
the interbase version and install fbclient.dll with the gds32.dll name
with the command
instclient -f i g
> If having two extensions already help (now and here), I can do what
> I've done for Oracle. We build two extensions for OCI9/10 and for
> OCI11g, they are built at the same time, both are available in the
> releases. It is then up to the users to choose the right versions. Is
> it something that could work for you? It will indeed introduce a
> little more support questions because of users using the wrong
> extension but it will at least allow us to use both interbase and
> firebird client libraries.
>
Do you mean that these libraries can built in two different
.\ext\interbase subdirectories? Try to explain:
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.
> I would appreciate if we can focus only about solving this issue for
> 5.3.0. It is possible to create new extensions for firebird (interbase
> is not my priority, if Borland likes to contribute it, they are free
> to do it) later via pecl and then merge into the core when it is
> ready.
>
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?

Thanks for patience you had to read my thoughts.

Ciao.
Mimmo.