Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:38254
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.122 cause and error)
Message-ID: <48552BF7.5060503@lsces.co.uk>
Date: Sun, 15 Jun 2008 15:49:27 +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: 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>
In-Reply-To: <fe05d1540806150322w502e7f73hb0e7ce4c0ac01ccb@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 Lester,
> 
> On Sun, Jun 15, 2008 at 10:40 AM, Lester Caine <lester@lsces.co.uk> wrote:
>> Lukas Kahwe Smith wrote:
>>> Ok, to spell it out one last time: If windows support cannot be provided
>>> in 5.3, there is a good chance that this will increase the likelihood that
>>> interbase driver will soon be out of PHP core, even if it still works on
>>> Linux. Also to remind you once again, our windows guy has gone missing and
>>> we are rebuilding things from scratch for 5.3. If this is not enough of a
>>> problem to fix, then so be it.
>> I've obviously missed something ....
>> If there is a problem simply providing a windows build of PHP5.x then that
>> is a different matter.
>> Still not saying I can help - but I have already spent some time having
>> another look at doing my own Windows builds. It looks like the same problem
>> I have with my own Firebird builds though ... need M$ tools to do the job :(
> 
> What we actually need is not C developers or new core developers
> (well, we do but it is not a requirement here).  We are missing tests
> (as in phpt which can be run using a firebird DB) and active users
> giving feedback and running these tests.

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. 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.

> 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 ;)
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?

>> 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.

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 :(

( To be honest *I* would rather remove pdo_firebird than php_interbase .... at 
least until pdo_firebird could be re-writen to replace php_interbase 
completely rather than our having to load both to get the functions currently 
lacking in pdo - but that is a separate discussion )

-- 
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