extensions status, to move to pecl or to drop

17 years ago by Pierre Joye — view source

unread

Hi,

While reviewing the different extensions for the windows build, I
found that many are unmaintained without any commit since year(s).
Other are already removed from HEAD and some may be continued to
live in core but it would require some love.

Extension being deleted (not removed, a "cvs rm" will be done)

mhash, no impact as we provide a compatibility layer via ext/hash
(Thanks to Scott)
Extension looking for love (if noone raises the hand, they will end
in PECL too)

ncurses
I can help here for the windows port and pdcurses support on unix and
windows. Hartmurt agreed for the move it to pecl for 5.3.
smnp
nice ext, any ISP out there willing to help? I can help for the windows support

Can be moved PECL

interbase
fpdf
fbsql
sybase and sybase_ct

Please let me know if you can either help to maintain an extension or
if you see any issue with one of these moves.

Cheers,

Pierre

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

17 years ago by Brian Moon — view source

unread

Pierre Joye wrote:

smnp
nice ext, any ISP out there willing to help? I can help for the windows support

Hmm, we use this. Is it broken for 5.3 or something? What do we need
to do to keep this alive?

Brian Moon
Senior Developer/Engineer

When you care enough to spend the very least.
http://dealnews.com/

17 years ago by Pierre Joye — view source

unread

Hi Brian,

Pierre Joye wrote:

smnp
nice ext, any ISP out there willing to help? I can help for the windows
support

Hmm, we use this. Is it broken for 5.3 or something? What do we need to do
to keep this alive?

It is not maintained, no one develops or maintains it. I successfully
build it on windows using the latest snmp libs, however it would be
much better if there was actually a maintainer. I sadly can't take
care of it alone and it does not make sense to keep a non maintained
extension in php. As snmp is not the most popular extension, I do
understand that it is really helpful to have good snmp support with
php. That's why I made a call for volunteers instead of putting it in
the "to be moved out" category.

Do you feel like you can give it some love?

Cheers,

Pierre

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

17 years ago by johannes@php.net — view source

unread

Hi,

Extension being deleted (not removed, a "cvs rm" will be done)

mhash, no impact as we provide a compatibility layer via ext/hash
(Thanks to Scott)

We should keep this somewhere in Siberia like we did with other
extensions we removed. (PHP 4 XML stuff for instance)

Extension looking for love (if noone raises the hand, they will end
in PECL too)

ncurses
I can help here for the windows port and pdcurses support on unix and
windows. Hartmurt agreed for the move it to pecl for 5.3.

hm, I thought this was already done, go for it.

smnp
nice ext, any ISP out there willing to help? I can help for the windows support

Last time I checked it worked nicely and I know other user which have no
problems either, so I guess there's not much maintenance needed. The
only thing I see is implementing new parameter parsing API.

So I don't see a reason to move it to PECL.

Can be moved PECL

interbase

fpdf

fbsql

sybase and sybase_ct

Moving fpdf shouldn't be a problem, for the others I can't really judge,
I don't know a user of these, but that's me.

johannes

17 years ago by Pierre Joye — view source

unread

hi,

Extension being deleted (not removed, a "cvs rm" will be done)

mhash, no impact as we provide a compatibility layer via ext/hash
(Thanks to Scott)

We should keep this somewhere in Siberia like we did with other
extensions we removed. (PHP 4 XML stuff for instance)

I was not clear, sorry. There is no point to keep it in siberia as the
whole user API will still be available. You can see this move as a
dependency removal. libmcrypt is not used anymore and the ext/mhash
functions will be implemented using ext/hash, in ext/hash.

Extension looking for love (if noone raises the hand, they will end
in PECL too)

ncurses
I can help here for the windows port and pdcurses support on unix and
windows. Hartmurt agreed for the move it to pecl for 5.3.

hm, I thought this was already done, go for it.

It will be done shortly.

smnp
nice ext, any ISP out there willing to help? I can help for the windows support

Last time I checked it worked nicely and I know other user which have no
problems either, so I guess there's not much maintenance needed. The
only thing I see is implementing new parameter parsing API.

So I don't see a reason to move it to PECL.

But who knows which minimum snmp version should be supported (I say
should not could)? What can I change on windows to support a decent
snmp version (don't look at the version we used now :)?

No one maintains it, the user base is relatively small (very small
even). We have moved working extensions to pecl in the past because
they were not maintained (and that's a very good reason). If you feel
like you can help to maintain it, please do it. As I said earlier, I
can give a hand to improve it and make it work smoothly on windows but
I can't do it alone.

Can be moved PECL

interbase

fpdf

fbsql

sybase and sybase_ct

Moving fpdf shouldn't be a problem, for the others I can't really judge,
I don't know a user of these, but that's me.

I'd to wait a couple of days but I think there is no issue to move them.

--
Pierre

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

17 years ago by Lukas Kahwe Smith — view source

unread

interbase

fbsql

sybase and sybase_ct

I think moving fbsql is quite reasonable. However interbase and sybase
I do not agree with.

regards,
Lukas Kahwe Smith
mls@pooteeweet.org

17 years ago by Pierre Joye — view source

unread

interbase

fbsql

sybase and sybase_ct

I think moving fbsql is quite reasonable. However interbase and sybase I do
not agree with.

Who will maintain them? Who can we ask when there is issues (besides
the obvious ones)?

Cheers,

Pierre

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

17 years ago by Lukas Kahwe Smith — view source

unread

On Sat, Jun 14, 2008 at 3:24 PM, Lukas Kahwe Smith
mls@pooteeweet.org wrote:

interbase

fbsql

sybase and sybase_ct

I think moving fbsql is quite reasonable. However interbase and
sybase I do
not agree with.

Who will maintain them? Who can we ask when there is issues (besides
the obvious ones)?

These extension seem widely used enough that we have to make it an
effort to support them. Removing them is removing a key feature our
user base experts to find. Now for PHP6 I see this a bit differently,
especially provided we have decent support for these databases via PDO.

regards,
Lukas Kahwe Smith
mls@pooteeweet.org

17 years ago by Pierre Joye — view source

unread

Hi Lukas,

These extension seem widely used enough that we have to make it an effort to
support them.

If it is so widely used, why noone complains about this removal? Why
there is nobody taking care of the bugs or sending patches?

That's why I doubt that these extensions are widely used. And if there
is users, they are in controlled environments like dedicated servers
or intranet and can then install them from PECL. If that makes you
feel better, I can make releases in PECL and post something about
their status.

Removing them is removing a key feature our user base experts
to find. Now for PHP6 I see this a bit differently, especially provided we
have decent support for these databases via PDO.

I don't see them as key features, and I doubt the PDO support will be
any better if no one actually care about them. It is even worst in the
case of firebird as even the firebird author(s) clearly stated what
they think about PDO and that they are not going to help (that's what
I understand).

Cheers,

Pierre

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

17 years ago by Rasmus Lerdorf — view source

unread

Pierre Joye wrote:

Hi Lukas,

These extension seem widely used enough that we have to make it an effort to
support them.

If it is so widely used, why noone complains about this removal? Why
there is nobody taking care of the bugs or sending patches?

I don't think this argument works very well. If we were to apply that
in general terms, we should probably drop Windows support completely
because there are pretty much no Windows users taking care of bugs, nor
sending patches. There are a couple, I don't want to make their
contributions seem insignificant, but the ratio of users to contributors
is terrible for the Windows platform.

For something like the SNMP extension, it works ok. SNMP isn't exciting
in any way. I did some work on it so it got to the point where it was
useful to me, and there have been a couple of requests over the years to
extend it, but I think for most people it does all it needs to do.

-Rasmus

17 years ago by Pierre Joye — view source

unread

Pierre Joye wrote:

Hi Lukas,

On Sat, Jun 14, 2008 at 4:26 PM, Lukas Kahwe Smith mls@pooteeweet.org
wrote:

These extension seem widely used enough that we have to make it an effort
to
support them.

If it is so widely used, why noone complains about this removal? Why
there is nobody taking care of the bugs or sending patches?

I don't think this argument works very well. If we were to apply that in
general terms, we should probably drop Windows support completely because
there are pretty much no Windows users taking care of bugs, nor sending
patches. There are a couple, I don't want to make their contributions seem
insignificant, but the ratio of users to contributors is terrible for the
Windows platform.

You are right, that's not a good argument. However I'm still not sure
about how it helps to have it in the core.

What if I release them through PECL of the current state and apply
patches or write fixes if there is reports and tests?

DLLs can be built as well using what we had in the last 5.2 releases.
That will make no difference for the users and will ease my work
(sorry to be egoist :).

For something like the SNMP extension, it works ok. SNMP isn't exciting in
any way. I did some work on it so it got to the point where it was useful
to me, and there have been a couple of requests over the years to extend it,
but I think for most people it does all it needs to do.

Agreed, that's why I made a call for love first and did not work well
so far. Maybe you can motivate Brian :)

Cheers,

Pierre

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

17 years ago by Richard Quadling — view source

unread

2008/6/14 Rasmus Lerdorf rasmus@lerdorf.com:

Pierre Joye wrote:

Hi Lukas,

On Sat, Jun 14, 2008 at 4:26 PM, Lukas Kahwe Smith mls@pooteeweet.org
wrote:

These extension seem widely used enough that we have to make it an effort

to
support them.

If it is so widely used, why noone complains about this removal? Why
there is nobody taking care of the bugs or sending patches?

I don't think this argument works very well. If we were to apply that in
general terms, we should probably drop Windows support completely because
there are pretty much no Windows users taking care of bugs, nor sending
patches. There are a couple, I don't want to make their contributions seem
insignificant, but the ratio of users to contributors is terrible for the
Windows platform.

I try!

And as I only use MSSQL, we should drop mySQL.

For something like the SNMP extension, it works ok. SNMP isn't exciting in
any way. I did some work on it so it got to the point where it was useful
to me, and there have been a couple of requests over the years to extend it,
but I think for most people it does all it needs to do.

-Rasmus

--

--

Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"

17 years ago by Lukas Kahwe Smith — view source

unread

Hi Pierre,

Like I said on IRC, if the ext end up being broken, but remain in core
they can get fixed and made available easily to all users. If we move
them, then this is no longer possible. We can revist this topic for
PHP6, but I do not think we should start dropping these extension in
5.3.

regards,
Lukas Kahwe Smith
mls@pooteeweet.org

17 years ago by Lester Caine — view source

unread

Lukas Kahwe Smith wrote:

interbase

fbsql

sybase and sybase_ct

I think moving fbsql is quite reasonable. However interbase and
sybase I do
not agree with.

Who will maintain them? Who can we ask when there is issues (besides
the obvious ones)?

These extension seem widely used enough that we have to make it an
effort to support them. Removing them is removing a key feature our user
base experts to find. Now for PHP6 I see this a bit differently,
especially provided we have decent support for these databases via PDO.

Apart from the problems created by changes made to the interbase driver in the
5.1 and early 5.2 cycle ( the 64 bit version of which STILL has not been
repaired :( ) the driver still works fine with modern builds of Firebird so
there as been no need to improve on it. Those of us who use it have not been
persuaded that PDO has any advantage as yet, especially when you add ADOdb in
as a back end, so there is NOT a suitable version of PDO for
interbase/firebird and no one is working on THAT, so PLEASE do not remove the
one package that is working well :(

As yet we have not identified any new functions in Firebird 2.1 that can not
still be accessed via current driver, so there has not even been a need to
spend time building an environment in which we can compile our own copies. The
binary versions supplied in Linux and Windows simply work.

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

17 years ago by Pierre Joye — view source

unread

Hi Lester,

Apart from the problems created by changes made to the interbase driver in
the 5.1 and early 5.2 cycle ( the 64 bit version of which STILL has not been
repaired :( ) the driver still works fine with modern builds of Firebird so
there as been no need to improve on it. Those of us who use it have not been
persuaded that PDO has any advantage as yet, especially when you add ADOdb
in as a back end, so there is NOT a suitable version of PDO for
interbase/firebird and no one is working on THAT, so PLEASE do not remove
the one package that is working well :(

You need it? Please help me to maintain and to provide reliable
binaries for windows or to keep it up to date when necessary (given
your comment below).

As yet we have not identified any new functions in Firebird 2.1 that can not
still be accessed via current driver, so there has not even been a need to
spend time building an environment in which we can compile our own copies.
The binary versions supplied in Linux and Windows simply work.

We are very reluctant to continue to release binaries where we have
zero ideas how we can update the dependencies without breaking
anything in the extension or in the end user applications. I would
have no problem to keep it and even to help to maintain it if (and
only if) I have someone knowing firebird and its php drivers well
enough to tell me if what I did works or not.

It is nice to complain how useless is PDO but it is way better to
actually contribute and help us to make your software working with PHP
:)

Cheers,

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

17 years ago by Lester Caine — view source

unread

Pierre Joye wrote:

Hi Lester,

Apart from the problems created by changes made to the interbase driver in
the 5.1 and early 5.2 cycle ( the 64 bit version of which STILL has not been
repaired :( ) the driver still works fine with modern builds of Firebird so
there as been no need to improve on it. Those of us who use it have not been
persuaded that PDO has any advantage as yet, especially when you add ADOdb
in as a back end, so there is NOT a suitable version of PDO for
interbase/firebird and no one is working on THAT, so PLEASE do not remove
the one package that is working well :(

You need it? Please help me to maintain and to provide reliable
binaries for windows or to keep it up to date when necessary (given
your comment below).

WHEN there is a need to maintain it the Firebird Foundation could be persuaded
to do so, the ONLY need for maintenance at the moment ids to fix bugs
introduced BY the continuing unnecessary changes in each build of PHP.

As yet we have not identified any new functions in Firebird 2.1 that can not
still be accessed via current driver, so there has not even been a need to
spend time building an environment in which we can compile our own copies.
The binary versions supplied in Linux and Windows simply work.

We are very reluctant to continue to release binaries where we have
zero ideas how we can update the dependencies without breaking
anything in the extension or in the end user applications. I would
have no problem to keep it and even to help to maintain it if (and
only if) I have someone knowing firebird and its php drivers well
enough to tell me if what I did works or not.

It is nice to complain how useless is PDO but it is way better to
actually contribute and help us to make your software working with PHP
:)

I would be more than happy to look at working on a PHP6 build of the
interbase driver tailored to the UNICODE build of Firebird 2.1. That is once
someone actually decides the base will be fore PHP6. I even installed a
development build of PHP6 some time ago, but if there is going to be TWO
versions of PHP6 then to be honest I am not interested. As soon as I can be
sure that we have one base for PHP6 then I will return to that development,
but PHP5.3 is just another totally unnecessary distraction. I have now got
php_interbase restored on PHP5.2.x so is there any need to bother my customers
with PHP5.3 - no. I'll wait now for PHP6 .....

--
Lester Caine - G8HFL

17 years ago by Steph Fox — view source

unread

Lester, hi,

I even installed a

development build of PHP6 some time ago, but if there is going to be TWO
versions of PHP6 then to be honest I am not interested.

There haven't been for the last couple of weeks. We're just waiting for
Scott to finish with the Engine work so that we can commit the rest and make
PHP core (and the core extensions) be always-on Unicode.

As soon as I can be sure that we have one base for PHP6 then I will return
to that development, but PHP5.3 is just another totally unnecessary
distraction.

PHP 5.3's our baby!!!!

I have now got

php_interbase restored on PHP5.2.x so is there any need to bother my
customers with PHP5.3 - no. I'll wait now for PHP6 .....

Poor customers. They'll miss all the benefits without the inevitable
performance loss.

As far as I'm aware there's nothing in PHP 6 that can't be supported from
PHP 5.2.1 up, but there's plenty in PHP 5.3 that a lot of developers will
like.

Steph

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

17 years ago by Lester Caine — view source

unread

Steph Fox wrote:

As far as I'm aware there's nothing in PHP 6 that can't be supported
from PHP 5.2.1 up, but there's plenty in PHP 5.3 that a lot of
developers will like.

AND SHOULD BE BEING DEVELOPED IN PHP6 SO WE CAN AT LEAST GET A CLEAN UNICODE
STABLE SYSTEM AVAILABLE TODAY !!!!!!

--
Lester Caine - G8HFL

17 years ago by Lars Strojny — view source

unread

Hi Lester,

Am Samstag, den 14.06.2008, 21:13 +0100 schrieb Lester Caine:
[...]

AND SHOULD BE BEING DEVELOPED IN PHP6 SO WE CAN AT LEAST GET A CLEAN UNICODE
STABLE SYSTEM AVAILABLE TODAY !!!!!!

Please, don't yell. KTHXBYE

cu, Lars

17 years ago by Steph Fox — view source

unread

As far as I'm aware there's nothing in PHP 6 that can't be supported from
PHP 5.2.1 up, but there's plenty in PHP 5.3 that a lot of developers will
like.

AND SHOULD BE BEING DEVELOPED IN PHP6 SO WE CAN AT LEAST GET A CLEAN
UNICODE STABLE SYSTEM AVAILABLE TODAY !!!!!!

Please don't shout, thanks, I'm nursing a headache.

Most of it was developed in CVS HEAD, and then back-ported to 5_3 when it
became clear that Unicode support is likely to take a while. Extensions
don't tend to be developed that way (ever), because the PECL system is such
that whatever's in CVS HEAD needs to work with the current release. But
that's all changing too.

Steph

17 years ago by Brian Moon — view source

unread

Pierre Joye wrote:

You need it? Please help me to maintain and to provide reliable
binaries for windows

This statements makes it sound like extensions that do not build on
Windows should be removed. That sounds insane to me. Please elaborate.
I must not understand what you are trying to say. I could care less
if any of PHP works on Windows. I am sure Richard feels the opposite. =)

Brian Moon
Senior Developer/Engineer

When you care enough to spend the very least.
http://dealnews.com/

17 years ago by Pierre Joye — view source

unread

Pierre Joye wrote:

You need it? Please help me to maintain and to provide reliable
binaries for windows

This statements makes it sound like extensions that do not build on Windows
should be removed.
That sounds insane to me. Please elaborate.

No, the statement is about no one actually being able to maintain it,
to solve possible issues or to answer questions about the code or how
it works. Making any change a possible breakage.

But the important point in my reply was my question :):

You need it? Please help me to maintain (it) and to provide reliable
binaries for windows

The binary part is only a good side effect of having a maintained extension.

I must not understand what you are trying to say. I could care less if any of PHP
works on Windows. I am sure Richard feels the opposite. =)

Now, to be honest, I don't care if 95% of our developers do not care
if PHP does not work on Windows. 99% of them will be the first to ask
to fix things as soon as users report issues or missing extensions.

But what you say is a good example on how we may act. Why should we
care for something we don't need? Because you need it? :)

Cheers,

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

17 years ago by Timm Friebe — view source

unread

Hi,

Can be moved PECL

interbase

fpdf

fbsql

sybase and sybase_ct

Sybase can be moved, it is unmaintained. I would've done this long ago if I
could, karma-wise.

Sybase_ct works perfectly for us at 1&1 and despite feature requests that
exist and me not having put big efforts into it over the past years it
serves millions of requests a day without problems. The next big step would
be to add all the if (unicode)-stuff needed for PHP6 and/or to port it to
a PDO driver, which I frankly don't have time to do.

If an extension is moved to PECL, it is a bit more of a hassle to install
it: Windows: instead of enabling it in php.ini you need to download the dll
(not sure who builds that? Is it done automatically?) / Un*x: Get a .tar.gz,
unpack, phpize, configure and make (last time I tried that didn't work for
me, must've been some wrong auto-whatever). Plus I'm not sure how developing
works, would you mess up your PHP checkout tree by copying the pecl/ext/XXX
to php-src/ext/XXX and the running all these magic autotools? Correct me if
I'm wrong here, but I guess that's what people on both sides - extension
developers and PHP users - are afraid of when you announce PECL-moves,
right? Before you say "PECL is not siberia" think about the following: If
PECL moves wouldn't hurt the user experience for any partys involved, why
would any extension live in php-src/ext/?

Timm

17 years ago by Pierre Joye — view source

unread

hi Timm,

Hi,

Can be moved PECL

interbase

fpdf

fbsql

sybase and sybase_ct

Sybase can be moved, it is unmaintained. I would've done this long ago if I
could, karma-wise.

Let see what other thinks about this one, I'm waiting a couple of days more.

Sybase_ct works perfectly for us at 1&1 and despite feature requests that
exist and me not having put big efforts into it over the past years it
serves millions of requests a day without problems. The next big step would
be to add all the if (unicode)-stuff needed for PHP6 and/or to port it to
a PDO driver, which I frankly don't have time to do.

And same for us. We don't the time or resources to support them (see below).

But if we work together, it should be possible to keep them. Let me
ask you the same than I ask to Lester, will you help us to keep
sybase_ct in php-src? You don't need to know C or php internals but to
actually provide tests and run them when we update the libraries or
releases RC. What would rock is to have it supported by gcov (by us or
somewhere else with a public report), would it be possible?

If an extension is moved to PECL, it is a bit more of a hassle to install
it: Windows: instead of enabling it in php.ini you need to download the dll
(not sure who builds that? Is it done automatically?)

It was done automatically and without much checks and tests but users
feedbacks after the releases. There is no need to say that it is not a
good way to do it.

Our position is that a dependency should be reliable, testable and
easy to update. That means that people should be able to test if a
dependency update or a change in the extension build/code did not
break anything. As we can do it easy for extensions with a large tests
suite or widely used, it is an impossible task for extensions like
sybase or interbase.

/ Un*x: Get a .tar.gz,
unpack, phpize, configure and make (last time I tried that didn't work for
me, must've been some wrong auto-whatever).

If the release is done correctly, a simple pecl install sybase works.

Cheers,

Pierre

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

17 years ago by Timm Friebe — view source

unread

Hi,

But if we work together, it should be possible to keep them. Let me
ask you the same than I ask to Lester, will you help us to keep
sybase_ct in php-src? You don't need to know C or php internals but to
actually provide tests and run them when we update the libraries or
releases RC.

There is a (small) number of tests:
http://cvs.php.net/viewvc.cgi/php-src/ext/sybase_ct/tests/

I can look into setting up a "cruise-control"-like infrastructure on our
dev-machines that'll run these periodically.

What would rock is to have it supported by gcov (by us or
somewhere else with a public report), would it be possible?

How can I get this done?

Timm

17 years ago by Pierre Joye — view source

unread

But if we work together, it should be possible to keep them. Let me
ask you the same than I ask to Lester, will you help us to keep
sybase_ct in php-src? You don't need to know C or php internals but to
actually provide tests and run them when we update the libraries or
releases RC.

There is a (small) number of tests:
http://cvs.php.net/viewvc.cgi/php-src/ext/sybase_ct/tests/

I can look into setting up a "cruise-control"-like infrastructure on our
dev-machines that'll run these periodically.

Thanks for the offer, that would be very helpful. Is it possible to
have it for windows as well? It could also help if we can get one
access to fix the possible bugs, as I don't have any sybase licenses
or access to any kind of Sybase server (other developers neither).

What would rock is to have it supported by gcov (by us or
somewhere else with a public report), would it be possible?

How can I get this done?

I'm adding Nuno to the loop, he is the one leading the gcov initiative
and will surely explain the setup in a better way than me :)

Grüße,

Pierre

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

17 years ago by Timm Friebe — view source

unread

Hi,
been busy again at work, sorry for the late answer.

I can look into setting up a "cruise-control"-like infrastructure on our
dev-machines that'll run these periodically.

Thanks for the offer, that would be very helpful. Is it possible to
have it for windows as well? It could also help if we can get one
access to fix the possible bugs, as I don't have any sybase licenses
or access to any kind of Sybase server (other developers neither).

I think it could be done on Windows also - let's see if my budget allows for
a Windows testing machine - if not, I'll (shhhhhh) use the production
server:)

Timm

17 years ago by Philip Olson — view source

unread

/ Un*x: Get a .tar.gz,
unpack, phpize, configure and make (last time I tried that didn't
work for
me, must've been some wrong auto-whatever).

If the release is done correctly, a simple pecl install sybase works.

This is an important point because unfortunately in the past a "moved
to PECL" was theoretical. Instead, if it meant the moved extension
could be found at pecl.php.net/extname, have its own bug category, and
be installable via the pecl command... the word "PECL" would be a lot
less scary. And it's worth noting that Pierre will release the
extensions mentioned in this thread so they won't be hidden in the
pecl CVS module.

And on a related note, have we considered any sort of fetch
integration with configure? You know, like --with-apc would grab it
much like 'pecl download apc' does today. Or more likely a trigger,
like --with-apc=fetch,beta ... you get the idea. A friendlier this[1].

Regards,
Philip

[1] http://php.net/install.pecl.static

17 years ago by Hartmut Holzgraefe — view source

unread

Pierre Joye wrote:

Can be moved PECL

interbase

fpdf

fbsql

sybase and sybase_ct

Please let me know if you can either help to maintain an extension or
if you see any issue with one of these moves.

i can help with fpdf if needed but it should go to PECL
nonetheless ...

--
Hartmut Holzgraefe, MySQL Regional Support Manager EMEA

Sun Microsystems GmbH, Sonnenallee 1, 85551 Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB161028
Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer
Vorsitzender des Aufsichtsrates: Martin Haering

17 years ago by Lester Caine — view source

unread

Pierre Joye wrote:

What I'm asking you is to help me to actually have a controllable and
testable firebird drivers in PHP. I will do my best to help you to get
things fixed and to provide the best windows binaries. However, one
thing is sure, I can't do it alone. For two reasons, I'm not a
firebird user and I have to learn it and I do not have the time or
resources to do it.

Please let me know if you or the firebird team is ready to help us to
improve the firebird support in php and in the end, to keep it in php.

THERE IS NOTHING WRONG WITH THE CURRENT FIREBIRD SUPPORT SO WHY DO WE NEED TO
IMPROVE IT? If something was missing it would be a different matter, but all
that is missing is a UNICODE only base to work from.

I have two problems with BUILDING windows binaries myself.

Being a long time Borland C++ house all of our compile system is set up for
Borland Builder5/6 and we have never moved on from that simple because all of
the new work is being done as PHP web applications.

I have been spending any spare time between running two businesses - neither
of which earn enough to pay the mortgage on their own :( - moving the legacy
windows code to Linux. And in Linux I have no problem playing with C++ code
without the need for open check-book to pay M$ exhortation. The main reason
for moving to PHP was to get out from under M$ but my customers still insist
on using Windows even where we show that Apache/PHP/Firebird performs better
on Linux.

The only thing that is holding up full use of UNICODE is the useless support
in PHP5 - something which I had anticipated would be solved with the release
of a PHP6 beta in 2007. We are half way through 2008 and there is not even a
hit of an Alpha PHP6 while PHP5 goalposts seem to be moving monthly :(

Until there is a roadmap to a production release of PHP6 then I am not going
to divert time to what I see as a dead end development and in the meantime I
am being threatened that if I don't help with this sidetrack the one component
of PHP that I consider essential will be removed :(

--
Lester Caine - G8HFL

17 years ago by Pierre Joye — view source

unread

hi Lester,

What I'm asking you is to help me to actually have a controllable and
testable firebird drivers in PHP. I will do my best to help you to get
things fixed and to provide the best windows binaries. However, one
thing is sure, I can't do it alone. For two reasons, I'm not a
firebird user and I have to learn it and I do not have the time or
resources to do it.

Please let me know if you or the firebird team is ready to help us to
improve the firebird support in php and in the end, to keep it in php.

THERE IS NOTHING WRONG WITH THE CURRENT FIREBIRD SUPPORT SO WHY DO WE NEED
TO IMPROVE IT? If something was missing it would be a different matter, but
all that is missing is a UNICODE only base to work from.

You mentioned at least one problem not fixed yet. But improving
something means that it works well and it will run even better
afterwards.

I have two problems with BUILDING windows binaries myself.

I have three problems with you now and here:

You keep getting loud. I'm not blind and I can read relatively good
even you write with lower cases
You refuse to see what I'm asking
You keep talking about pears when I'm asking about apples

The main reason for moving to PHP was to get out from under M$ but
my customers still insist on using Windows even where we show
that Apache/PHP/Firebird performs better on Linux.

Playing off base. What I proposed you is to help us to get your
software continue to run smoothly with PHP, while keeping the windows
support. In the end you may even get a faster version on windows, but
I suppose you don't care about that (poor customers ;).

Until there is a roadmap to a production release of PHP6 then I am not going
to divert time to what I see as a dead end development and in the meantime I
am being threatened that if I don't help with this sidetrack the one
component of PHP that I consider essential will be removed :(

You are completely missing my point (and it was crystal clear). I call
for help to be able to actually keep firebird/interbase support in php
core and you see that as a threat. I proposed you a way to make sure
that everything continue to work fine and you rejected it. Please feel
free to continue to shout at us for being so mad to manage releases in
time and in our free time. I'm done now with my poor attempt to solve
the interbase maintenance problem.

--
Pierre

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

17 years ago by Lukas Kahwe Smith — view source

unread

Pierre Joye wrote:

What I'm asking you is to help me to actually have a controllable and
testable firebird drivers in PHP. I will do my best to help you to
get
things fixed and to provide the best windows binaries. However, one
thing is sure, I can't do it alone. For two reasons, I'm not a
firebird user and I have to learn it and I do not have the time or
resources to do it.
Please let me know if you or the firebird team is ready to help us to
improve the firebird support in php and in the end, to keep it in
php.

THERE IS NOTHING WRONG WITH THE CURRENT FIREBIRD SUPPORT SO WHY DO
WE NEED TO IMPROVE IT? If something was missing it would be a
different matter, but all that is missing is a UNICODE only base to
work from.

I have two problems with BUILDING windows binaries myself.

Being a long time Borland C++ house all of our compile system is set
up for Borland Builder5/6 and we have never moved on from that
simple because all of the new work is being done as PHP web
applications.

Lester .. everybody has work and bills to pay etc. But the fact of the
matter is that PHP still needs to keep going .. and hopefully not in
spite of this .. but because people make enough money using PHP that
they can help in doing PHP.

So Pierre is hitting on some realities. We are rebuilding the entire
windows build infrastructure from scratch .. or rather the windows
team is. PHP has traditionally made it really easy for people to
develop apps on every OS. So supporting something just for *nix is
going to confuse our user base. Of course *nix will always get the
bulk of the focus, but just saying something works fine on *nix so
nothing is wrong if it does not build in windows is not an option.

What Pierre was also pointing out is if something is used by so few
people that there is only a single person who could in theory have an
interest in fixing this, but for personal reason is unable to do so
because he does not have any time cycles to spare (which is of course
entirely ok .. its a reality of life), then maybe this feature is not
worthy of core attention.

So if you or any one in the Firebird/Interbase community does have the
time and skills, please make it known to him that Firebird/Interbase
support is on the way out of PHP. Getting issues resolved in every
other minor release is not an option. Support needs to be solid in
every minor release.

And while you complain about PHP 5.3 and the lack of PHP 6. It might
remind you about the situation you just described. People have to
juggle their PHP dev time with their professional and private life's
and apparently getting PHP 6 out the door does not put food on the
table for enough people. Again this sounds strikingly similar to the
situation you described about why you personal have no (business)
interest in working on fixing up the windows builds for PHP 5.3. So
please can you stop the shouting.

regards,
Lukas Kahwe Smith
mls@pooteeweet.org

extensions status, to move to pecl or to drop

Cheers,

Brian Moon Senior Developer/Engineer

Cheers,

Cheers,

Cheers,

Cheers,

--

-- Lester Caine - G8HFL

Cheers,

-- Lester Caine - G8HFL

-- Lester Caine - G8HFL

-- Lester Caine - G8HFL

Brian Moon Senior Developer/Engineer

Cheers,

Cheers,

Grüße,

-- Lester Caine - G8HFL

Brian Moon
Senior Developer/Engineer

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL

Brian Moon
Senior Developer/Engineer

--
Lester Caine - G8HFL