Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:38257
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 213.123.20.119 cause and error)
Message-ID: <485541CF.6030503@lsces.co.uk>
Date: Sun, 15 Jun 2008 17:22:39 +0100
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.13) Gecko/20080313 SeaMonkey/1.1.9
MIME-Version: 1.0
To: Pierre Joye <pierre.php@gmail.com>
CC: PHP internals <internals@lists.php.net>
References: <4854BCAC.8090001@lsces.co.uk>	 <9C3DF443-1D06-4654-B519-4AABD37B9806@pooteeweet.org>	 <4854C9C7.6080302@lsces.co.uk>	 <8C383A08-257C-4D12-A170-3C02D970C23D@pooteeweet.org>	 <4854D588.2070601@lsces.co.uk>	 <fe05d1540806150322w502e7f73hb0e7ce4c0ac01ccb@mail.gmail.com>	 <48552BF7.5060503@lsces.co.uk> <fe05d1540806150811k3604dc0bv55f855db3f652490@mail.gmail.com>
In-Reply-To: <fe05d1540806150811k3604dc0bv55f855db3f652490@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] The battle between users and developers
From: lester@lsces.co.uk (Lester Caine)

Pierre Joye wrote:
> hi,
> 
> On Sun, Jun 15, 2008 at 4:49 PM, Lester Caine <lester@lsces.co.uk> wrote:
> 
>> Well when I originally reported the problems that were creeping into
>> php_interbase (linux and windows) I was told that *I* should fix them, and I
>> keep being told I should get involved more.
> 
> Not easy to fix issues yourself but you are getting amazingly more
> involved, this step is more than welcome!

I've always been monitoring and testing - but my main activity is USING in a 
number of other projects ;)
I should have been fixing bitweaver on windows today :(

>> So
>> http://lsces.co.uk/lsces/wiki/index.php?page=PHPDevelopment
>> Had the M$ express stuff installed on my backup W2k machine it would
>> probably not have been a problem, but I can't upgrade it since I need W2k on
>> that machine to test against ;)
>> I've been through the mill with M$ installs trashing the rest of my
>> development environment in the past, so I am not going to risk it again.
> 
> In the meantime I tried to build the 2.1.x releases (1.x dsw/dsp do
> not even want to be opened by vc6). It seems to work well but I met a
> couple of issues due to the wrong architecture detection (it uses the
> processor I use instead of actually using the current configartion,
> you can compile for x86 on x64 or cross compile for x64 on x86).
> Patches on their way, I suppose I can send them to firebird-developer?

http://tracker.firebirdsql.org/

> By the way, do you know if the 2.1 lib is 100% BC compatible with the
> 1.x serie? If yes, I can then use them for the php windows binaries.

The 2.1 client should access data from any older version of the server. 
Certainly I have no problems with FB1 running on W98SE ( Yes we still have to 
support that :( ) or 1.5 on Linux or Windows and I was still running IB5.6 
until recently without a problem.

>>> If you can write tests (you and the PHP firebird community) and run
>>> them using our sources and binary releases, that will already do the
>>> job. That's all we need to keep the extension alive.
>> Testing is not a problem ESPECIALLY while we can run multiple versions of
>> PHP on windows without the crap loaded into other applications which trash
>> the working version and overload it with a version which may not work. I
>> DON'T go with code that only has windows installers and would not test them
>> ;)
> 
> It is rather simple to run multiple PHP version on windows. You only
> have to uncompress the zip and run the tests. The fbclient will be
> statically linked (bundled in the ext). You can call the run-tests.php
> using the tests and script available in the src releases. I remember a
> howto somewhere about running tests on windows without using nmake, I
> will try to find it back.

There was talk about dropping the .zip because the 'installer' was available. 
Hopefully that idea has died on the vine.

>> http://fbexport.sourceforge.net/ibtest.php.txt is our base set of tests and
>> this shows a problem with NUMERIC(18,7) and above so we avoid that.
>>
>> The problem is fixing the problems we find?
> 
> Can you elaborate please? Or is there a bug # in bugs.php.net?

Fixed - http://bugs.php.net/bug.php?id=39700
but I try and avoid snapshots so I can't test yet.
42266 is the remaining niggle that is assigned to abies and the only one of 
the other bugs open needs checking to see what that problem is (43674)

>>>> I have an older windows server that is running as backup at present which
>>>> I
>>>> could safely load some of the M$ stuff on - if it will work on W2k .....
>>>> But I'd prefer to stay inside my safety zone .....
>>> We can take care of the builds and port the firebird clients libraries
>>> to Windows and/or MS tools. But we can do it only if we have a way to
>>> test them :)
>> THAT is an area where we do need to sort things out since the supplied
>> client library is always ditched anyway and the current Firebird one used
>> instead. From my point of view, splitting the fbird_ code from the ibase_
>> code and building php_firebird against a firebird client would make sense,
>> but as has already been said - is not actually necessary - yet.
> 
> Good point, especially as interbase is actually dead. That will simply
Interbase is not dead! As soon as the Inprise/Borland accountants realised 
what they had done in trying to end of life it they tried to closed the door 
again. http://www.codegear.com/products/interbase - rather costly especially 
when Firebird is available free.

> reflect the fact and we may add new 2.1 (or later) features. Feel free
> to create the fbclient page in the wiki and to document what could be
> done for 6.x (can't be renamed for 5.3).
Not sure that there is anything new to be done.
Main thing I think is transparent unicode. Firebird has always supported 
different collations/codesets per field in a table so has not had the 
restriction of other databases - which only supported a single codeset per 
database. Making everything UTF8 just simplifies everything in one hit and 
wipes out the need to manage code tables on a field by field basis :( I think 
that is one of the things that PDO would not allow, but it's been a while 
since I looked.

>> http://wiki.php.net/internals/windows/libs
>> The pages for ibase and fbclient need creating, and the project link for
>> interbase should be ibase but I could not work out what information should
>> be on them. In the past I have also been told that *I* need to make
>> pdo_firebird actually work which is yet another hassle that needs sorting
>> even if the current Firebird users do not use it :(
> 
> I can provide the libs in the next days as well as use them in our
> binaries snapshops (5.3, 6.x, maybe 5.2 if it works well and is 100%
> BC).
Static linking the client library may be a problem! Flamerobin needs to use 
the client for database management, and my legacy applications run in parallel 
on some machines. I run multiple web servers each with their own local legacy 
hardware but sharing data on a remote server.

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/lsces/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php