On Tue, Oct 14, 2008 at 6:40 PM, masotti <masotti@...> wrote:

> 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. :)

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.

> 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).

>> - 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.

We all do that in our free 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"?

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.

> 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 :)

> AFAIU testing without a goal isn't even an useful exercise.

it is useful to allow us to fix bugs without breaking every single
Firebird app out there :)

>> - 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.

Again, I'm talking about ext/interbase and pdo_firebird extensions, it
is what we have now and what we have to use for 5.3.0. ext/interbase
(php_interbase.*) is supposed to work with firebird and interbase, if
we have to build two extensions like what we do for Oracle, then let
do it.

>> 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.

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.

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...

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).

>> 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?

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.


> Thanks for patience you had to read my thoughts.

Thanks you for finally explain me what the firebird community needs,
that will hopefully bring us to the right solution :)

Cheers,
--
Pierre

http://blog.thepimp.net | http://www.libgd.org