Subject | Re: [firebird-php] PHP Driver status |
---|---|
Author | Lester Caine |
Post date | 2008-10-14T04:53:45Z |
pierre_php wrote:
Personally I have never liked the architecture of the PDO drivers and I still
don't. Scrapping stable and fast native drivers in favour of a structure that
only addresses half the problem still does not seem right, and as far as I am
concerned PDO needs a lot of work to restore performance especially when
linked to ADOdb which to some extent it competes directly with but for which
it is not a replacement. Since the problem that ADOdb addresses has been
specifically blocked from the PDO development path then there is little
incentive to 'fix' a competing package, but it is PDO's development that has
further divided database users in PHP and driven people who used to be
involved away :(
PHP that required re-writes to the code were never tested properly, and so
early 5.2.x versions introduced some bugs, which as far as I am concerned have
been fixed in 5.2.6 although some additional bugs have now been addressed in
5.2.7 ( ones which I've not been hitting )
And our own test suit is currently clear?
So what am I missing?
I've been programming in C for years using Borland tools - but that is now
stopping me actually building PHP ( and also strangely Firebird given it's
links with Borland ) since I can't afford to damage the Borland development
environment.
Firebird from Interbase. Personally this is not a problem since I have no
plans to install Interbase on a system, so can just use the right client, but
many current Codegear developers get it installed automatically with their
development system and then switching back to Firebird is a problem!
The only code changes that I see between an Interbase and a Firebird build
today are a change to the client name, and splitting the ibase and fbird
function definitions. This will then give a php_firebird with very little
effort - and is something *I* have no problem spending time undertaking - but
needs someone with the right 'karma' to create the new module in the PHP CVS.
Until there is something to patch, those of us who do not have 'karma' have no
way of creating patches for review in order to obtain it - which makes
contributing to the code base difficult? THAT was why we were told by the PHP
team that they just needed things being tested.
We seem to have a chicken and egg problem in that until there is something
that actually needs fixing we can't became involved in maintaining the driver?
I switched to PHP just before PHP5 was released simple because I needed to
replace c based applications and now I'm still being controlled by c based
windows code :(
--
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
> In the last six months, we had a couple of discussions about FirebirdThe discussion on PHP has been a bit one sided and I'm not entirely sure why :(
> support in PHP. You certainly know that there is not much activities
> around it, despite our numerous calls for help or support. If nothing
> changes in a near future, the firebird extension may be moved out of
> the PHP core (to PECL). But the immediate consequence affects only the
> windows users, 5.3.0 does not have the driver enabled and will not
> have it if we have no reliable way to provide secure and stable
> binaries.
Personally I have never liked the architecture of the PDO drivers and I still
don't. Scrapping stable and fast native drivers in favour of a structure that
only addresses half the problem still does not seem right, and as far as I am
concerned PDO needs a lot of work to restore performance especially when
linked to ADOdb which to some extent it competes directly with but for which
it is not a replacement. Since the problem that ADOdb addresses has been
specifically blocked from the PDO development path then there is little
incentive to 'fix' a competing package, but it is PDO's development that has
further divided database users in PHP and driven people who used to be
involved away :(
> That's all for the status.For me the php_interbase driver has been stable for a long time. Changes to
>
> What can be done or what can you do to help us to provide what you need?
> * You know PHP and use the current drivers in your project?
PHP that required re-writes to the code were never tested properly, and so
early 5.2.x versions introduced some bugs, which as far as I am concerned have
been fixed in 5.2.6 although some additional bugs have now been addressed in
5.2.7 ( ones which I've not been hitting )
> - Help us to write unit tests, review the current bug reports andThe tests have been updated?
> provide usable test cases to help the core developer to reproduce and
> fix a bug
> - Report bugs help too :)
And our own test suit is currently clear?
So what am I missing?
> * You know C (a bit) and building the firebird clients to be used withSo why is php_interbase simply not being included in the builds currently?
> PHP has no secret for you?
> - Please contact me, I will proudly help you to get your libs used by
> our builds system and restore firebird support in php 5.3.0+ on
> Windows!
I've been programming in C for years using Borland tools - but that is now
stopping me actually building PHP ( and also strangely Firebird given it's
links with Borland ) since I can't afford to damage the Borland development
environment.
> Thanks for your time, I hope this call will help to finally solve theGoing forward, now that Interbase is taking it's own path, we do need to split
> current Firebird issues in PHP.
Firebird from Interbase. Personally this is not a problem since I have no
plans to install Interbase on a system, so can just use the right client, but
many current Codegear developers get it installed automatically with their
development system and then switching back to Firebird is a problem!
The only code changes that I see between an Interbase and a Firebird build
today are a change to the client name, and splitting the ibase and fbird
function definitions. This will then give a php_firebird with very little
effort - and is something *I* have no problem spending time undertaking - but
needs someone with the right 'karma' to create the new module in the PHP CVS.
Until there is something to patch, those of us who do not have 'karma' have no
way of creating patches for review in order to obtain it - which makes
contributing to the code base difficult? THAT was why we were told by the PHP
team that they just needed things being tested.
We seem to have a chicken and egg problem in that until there is something
that actually needs fixing we can't became involved in maintaining the driver?
I switched to PHP just before PHP5 was released simple because I needed to
replace c based applications and now I'm still being controlled by c based
windows code :(
--
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