On 23.06.2008, at 14:54, Milan Babuskov wrote:
Lukas Kahwe Smith wrote:
if nobody with C hacking skills is feeling sufficient pain over
this, the assumption is that the pool of users is too small or the
pain is too small.
sorry for such late reply, but I just joined this group. I'm very
interested in Firebird's future in PHP and I have C skills. However,
to answer your assumption: the pain is too small.
We have a working 'interbase' extenstion that does all the job, and
does it well. I see that it might get moved to PECL or it might not,
however, it is going to be working for a long time. Current PHP
+Firebird users just don't feel that they need PDO.
It could be used for new application development, but you'll hardly
find a novice PHP user that is also willing to start hacking into
PHP source code in parallel. Existing users are simply happy with
pure ibase_ functions and ADOdb.
Now, I don't know about that 'lot of shiny new software' being
written on PDO, and don't really see that Firebird users will care
much. Most of that software is meant to run for ISPs, hosting, etc.
services and Firebird is still not on par with MySQL in that (web
hosting) environment. I use Firebird for everything, except dynamic
online websites where MySQL is simply the best choice.
Its not only shiny software, its pretty much all of the standard libs
people are developing. So even if you use PHP+Firebird for other stuff
you will probably be unhappy that you cannot really use any of the
database enabled libs in ezc and ZF. The same will probably be true
for PEAR2 etc.
I hope that PDO stuff is not meant to completely replace mysql_,
ibase_, etc. kind of functions in some distant future.
It does not seem like its going to happen in the immediate future (aka
PHP 6.0) unless we will that we have nobody to contact in case of bugs
and more importantly that ensures that we are aware of security
issues. So for now it would be sufficient someone steps up and takes
over the maintainer role for the ibase extension. This would entail
doing the standard maintenance stuff like updating to the new
parameter parsing API. It would also entail proactively addressing
security issues. Obviously for PHP 6.0 we do need someone to update
things for full unicode support eventually as well.
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
