This is an exploratory e-mail, so don't panic just yet :-). I am
thinking of moving the COM, mhash and socket extensions to PECL in
5.2 and 6.0 releases and was hoping to hear for & against arguments.
The reason for the making this move are as follows:
COM:
Un-maintained at this time and has a fairly serious number of bugs
(26 by latest count, many of which are crashes)
Only usable to Win32 users, which I think we all admit are a
minority and can always download readily available binaries from
pec4win. Since most of them don't compile the extension from source
anyway there is IMHO little reason to bundle the sources with every
php package.
Moving it to PECL will allow for an independent release cycle, which
may allow for faster fix deployment etc...
I hoping the move will encourage people and/or companies to start
maintaining the extension.
mhash:
Everything this extension that relies on an external lib to do, is
already done by hash extension that is enabled by default and
requires no external libs. There is simply no reason to keep it around.
sockets:
Un-maintained.
Majority of what it can do can already by done via streams in a much
more consistent and stable fashion.
Ilia Alshanetsky
Ilia Alshanetsky wrote:
COM:
+1
mhash:
+1
sockets:
+1
--
Sebastian Bergmann http://sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69
COM:
mhash:
sockets:
+1 +1 +1
--
Wbr,
Antony Dovgal
COM:
Un-maintained at this time and has a fairly serious number of bugs
(26 by latest count, many of which are crashes)
I don't think COM should be moved out. Right, it's windows only - but if
you are on windows, COM extension is most useful (I used it a number of
times and it's really amazing how easily you can do various data
processing stuff if you combine power of PHP with, for example, Excel).
As for bugs, they certainly need some attention, only moving it to PECL
is not going to do them any better :) And as far as I can see, COM
extension does not consume any significant resources. So I don't think
it's a good idea to move it out.
mhash:
Everything this extension that relies on an external lib to do, is
already done by hash extension that is enabled by default and requires
no external libs. There is simply no reason to keep it around.
Sounds convincing to me. Only thing I see is that manual right now does
not give clear idea of what algorithms hash extension supports. It's not
an argument against moving mhash out but suggestion for improvement :)
sockets:
Un-maintained.
Majority of what it can do can already by done via streams in a much
more consistent and stable fashion.
The I guess it's ok to move it to 6.0 but I don't think it's ok for 5.2
since there's a potential for people using it in apps and streams has
quite different API so it'd require significant rewrite if people want
to use it with standard PHP. Thus, not good to change it in minor version.
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/
COM:
Un-maintained at this time and has a fairly serious number of
bugs (26 by latest count, many of which are crashes)I don't think COM should be moved out. Right, it's windows only -
but if you are on windows, COM extension is most useful (I used it
a number of times and it's really amazing how easily you can do
various data processing stuff if you combine power of PHP with, for
example, Excel). As for bugs, they certainly need some attention,
only moving it to PECL is not going to do them any better :) And as
far as I can see, COM extension does not consume any significant
resources. So I don't think it's a good idea to move it out.
Well, it does not consume any resources simply because no one is
maintaining it ;-). How really different things would be if it were
in pecl? I mean afaik COM is not enabled by default on win32, so you
still need to enable it manually. So, the only extra step for people
who want to use it would be to download it from pecl4win. This
updates extensions more frequently then we do releases, so it'd
actually give people the ability to get a more stable version
(assuming bug fixes are made) far sooner then they'd be able to
otherwise.
mhash:
Everything this extension that relies on an external lib to
do, is already done by hash extension that is enabled by default
and requires no external libs. There is simply no reason to keep
it around.Sounds convincing to me. Only thing I see is that manual right now
does not give clear idea of what algorithms hash extension
supports. It's not an argument against moving mhash out but
suggestion for improvement :)
There is a list on http://www.php.net/manual/en/function.hash-
algos.php, but I agree that we need a clearer list on the main page
of the docs for the hash extension.
sockets:
Un-maintained.
Majority of what it can do can already by done via streams in
a much more consistent and stable fashion.The I guess it's ok to move it to 6.0 but I don't think it's ok for
5.2 since there's a potential for people using it in apps and
streams has quite different API so it'd require significant rewrite
if people want to use it with standard PHP. Thus, not good to
change it in minor version.
A good point for 5.2, but given that there is no one to support users
using this extension if people start using that extension they
potentially leading themselves to a dead-end. Given how far the
streams have gone lately I do not believe that there is any interest
in maintaining this extension any further.
Ilia Alshanetsky
Well, it does not consume any resources simply because no one is
maintaining it ;-). How really different things would be if it were in
I meant runtime resources, not developer resources. Like memory, CPU, etc :)
pecl? I mean afaik COM is not enabled by default on win32, so you still
need to enable it manually. So, the only extra step for people who want
AFAIK it's not the case. In my builds COM is always enabled and I didn't
do anything special. And PECL extension means "no support by standard
PHP, you need to do additional effort to get it", which is not good
IMHO. COM is pretty basic functionality on Windows.
A good point for 5.2, but given that there is no one to support users
using this extension if people start using that extension they
potentially leading themselves to a dead-end. Given how far the streams
We can have notice to that effect in the manual, so that people starting
using it (who presumably read the manual before they start writing the
code :) would know to move to streams. My concern is not new users but
existing code.
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/
Hi,
COM:
+1, easy to install from pecl.
mhash:
sockets:
Un-maintained.
A good point for 5.2, but given that there is no one to support users
using this extension if people start using that extension they
potentially leading themselves to a dead-end. Given how far the
streams have gone lately I do not believe that there is any interest
in maintaining this extension any further.
In my opinion we shouldn't remove these (mhash and sockets) from a minor
release, instead we should mark them as deprecated (using
ZEND_ACC_DEPRECATED) so everybody (who cares) get's the error message
and can change his code and we can remove it in 5.3/6.0 without users
complaining too much.
johannes
Ilia Alshanetsky wrote:
Well, it does not consume any resources simply because no one is
maintaining it ;-). How really different things would be if it were in
pecl? I mean afaik COM is not enabled by default on win32, so you still
need to enable it manually. So, the only extra step for people who want
to use it would be to download it from pecl4win. This updates extensions
more frequently then we do releases, so it'd actually give people the
ability to get a more stable version (assuming bug fixes are made) far
sooner then they'd be able to otherwise.
You know wrongly, COM is enabled and built in static as default.
Removing it would be a very bad idea IMO, and I don't see why unix users
should worry a few extra K in the source tarball.
Edin
I'm OK with all except for COM.
I've actually used the COM extension quite a bit internally here for
reporting and creating Excel files (see one of my blog postings from about a
year ago). I think for those who are on Windows it's a really handy
extension. Last time I checked it was also always enabled and available
which is useful. It also makes sense because when other modules need COM to
be initialized it shoud be done only once in the PHP core and so should be
available (kind of like libxml serves the other XML extensions).
As far as finding a maintainer is concerned, we can check again with Wez. If
he doesn't have time we should probably be able to find someone who can look
into some of those bugs. Despite bugs, I've never had issues with it.
Andi
-----Original Message-----
From: Ilia Alshanetsky [mailto:iliaal@gmail.com] On Behalf Of
Ilia Alshanetsky
Sent: Friday, December 08, 2006 8:03 AM
To: PHP internals
Subject: [PHP-DEV] Moving COM, Socket & mhash to PECLThis is an exploratory e-mail, so don't panic just yet :-).
I am thinking of moving the COM, mhash and socket extensions
to PECL in
5.2 and 6.0 releases and was hoping to hear for & against arguments.
The reason for the making this move are as follows:COM:
Un-maintained at this time and has a fairly serious
number of bugs
(26 by latest count, many of which are crashes)
Only usable to Win32 users, which I think we all admit
are a minority and can always download readily available
binaries from pec4win. Since most of them don't compile the
extension from source anyway there is IMHO little reason to
bundle the sources with every php package.
Moving it to PECL will allow for an independent release
cycle, which may allow for faster fix deployment etc...
I hoping the move will encourage people and/or
companies to start maintaining the extension.mhash:
Everything this extension that relies on an external
lib to do, is already done by hash extension that is enabled
by default and requires no external libs. There is simply no
reason to keep it around.sockets:
Un-maintained.
Majority of what it can do can already by done via
streams in a much more consistent and stable fashion.Ilia Alshanetsky
--
To
unsubscribe, visit: http://www.php.net/unsub.php
As far as finding a maintainer is concerned, we can check again with Wez. If
he doesn't have time we should probably be able to find someone who can look
into some of those bugs. Despite bugs, I've never had issues with it.
I'm currently (way!) too busy to look at it, but it sounds like Frank
and Pierre have volunteered some time. I'll happily review patches.
--Wez.
Wez Furlong wrote:
As far as finding a maintainer is concerned, we can check again with
Wez. If
he doesn't have time we should probably be able to find someone who
can look
into some of those bugs. Despite bugs, I've never had issues with it.I'm currently (way!) too busy to look at it, but it sounds like Frank
and Pierre have volunteered some time. I'll happily review patches.--Wez.
Hi Internals
I am still pretty new to PHP but having spent the last couple of
months reviewing the PHP code and
getting to know how PHP ticks I would be happy to volunteer some time
take a look at some of the
outstanding issues with the COM extension. I am about to go on vacation
for a couple of weeks but I
will certainly have time early in 2007 to investigate some of the OPEN
defects.
As a couple of others (Frank and Pierre) have also volunteered time
whats the best way to work this so that
we make best use of our time. Should I just add add a comment to a
defect when I start investigating it and
then post any fixes I come up with to list for review ?
Regards
Andy
Andy Wharmby
IBM United Kingdom Limited
Hi Internals
I am still pretty new to PHP but having spent the last couple of
months reviewing the PHP code and
getting to know how PHP ticks I would be happy to volunteer some time
take a look at some of the
outstanding issues with the COM extension. I am about to go on vacation
for a couple of weeks but I
will certainly have time early in 2007 to investigate some of the OPEN
defects.As a couple of others (Frank and Pierre) have also volunteered time
whats the best way to work this so that
we make best use of our time. Should I just add add a comment to a
defect when I start investigating it and
then post any fixes I come up with to list for review ?
Yes, that would work.
Thanks.
--
Wbr,
Antony Dovgal
Hello,
This is an exploratory e-mail, so don't panic just yet :-). I am
thinking of moving the COM, mhash and socket extensions to PECL in
5.2 and 6.0 releases and was hoping to hear for & against arguments.
The reason for the making this move are as follows:COM:
Un-maintained at this time and has a fairly serious number of bugs
(26 by latest count, many of which are crashes)
It has a lot of bugs yes, but it is useful and works well for many
situations. I do not like the idea to move it out of php.
Moving it to PECL will allow for an independent release cycle, whichmay allow for faster fix deployment etc...
It is possible without moving it out. It could even be a good thing to do it.
I hoping the move will encourage people and/or companies to startmaintaining the extension.
There is bugs and it is expected, COM allows a lot of things with a
lot of external apps, no wonder. But it works well (for what I did at
least, office, IE and XML com). I can try to take a look at the open
bugs if Wez is missing the time.
mhash:
Everything this extension that relies on an external lib to do, is
already done by hash extension that is enabled by default and
requires no external libs. There is simply no reason to keep it around.
We may move it from php 6.0 and up or at least from 5.3.0.
sockets:
Un-maintained.
Majority of what it can do can already by done via streams in a much
more consistent and stable fashion.
+1 from php 6.0 and up but I'm worrying a bit about 5.x code relying on it.
--Pierre
This is an exploratory e-mail, so don't panic just yet :-). I am thinking of
moving the COM, mhash and socket extensions to PECL in 5.2 and 6.0 releases
and was hoping to hear for & against arguments.
The reason for the making this move are as follows:COM:
-1, but we need somebody to have a look at the issues there.
mhash:
+1
sockets:
-1 in 5.x, +1 in 6.0 as there are still many people who use this stuff.
Also we need to make sure that all the stuff done by ext/socket can also
be done by the streams in some way.
regards,
Derick
At 21:51 08/12/2006, Derick Rethans wrote:
This is an exploratory e-mail, so don't panic just yet :-). I am
thinking of
moving the COM, mhash and socket extensions to PECL in 5.2 and 6.0 releases
and was hoping to hear for & against arguments.
The reason for the making this move are as follows:COM:
-1, but we need somebody to have a look at the issues there.
mhash:
+1
sockets:
-1 in 5.x, +1 in 6.0 as there are still many people who use this stuff.
Also we need to make sure that all the stuff done by ext/socket can also
be done by the streams in some way.
Same as Derick and Stas.
Zeev
COM:
Un-maintained at this time and has a fairly serious number of bugs
(26 by latest count, many of which are crashes)
Only usable to Win32 users, which I think we all admit are a
minority and can always download readily available binaries from
pec4win. Since most of them don't compile the extension from source
anyway there is IMHO little reason to bundle the sources with every
php package.
Moving it to PECL will allow for an independent release cycle, which
may allow for faster fix deployment etc...
I hoping the move will encourage people and/or companies to start
maintaining the extension.
+1, so long as the php_com.dll or whatever is readily available
somewhere.
mhash:
Everything this extension that relies on an external lib to do, is
already done by hash extension that is enabled by default and
requires no external libs. There is simply no reason to keep it
around.
+1
sockets:
Un-maintained.
Majority of what it can do can already by done via streams in a much
more consistent and stable fashion.
This one maks me nervous...
Seems like this would get used a fair amount for legacy code to run
custom web app/server stuff...
I guess anybody smart enough to do that and make it work ought to be
able to find/install a PECL extension, though, eh?
+0.8
--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?
COM:
Un-maintained at this time and has a fairly serious number of bugs
(26 by latest count, many of which are crashes)
But aside from those problems (which I suspect are mostly duplicates),
it works fine for the majority of users.
As I told you on IRC, I am not aware of it being critically flawed to
the point where it needs to be removed.
Only usable to Win32 users, which I think we all admit are aminority and can always download readily available binaries from
pec4win. Since most of them don't compile the extension from source
anyway there is IMHO little reason to bundle the sources with every
php package.
I also tried to convey that COM is an essential core technology on Windows.
Removing it is a very bad idea. It's a bit like suggesting that we
make the exec family of functions an optional download. In theory, it
sounds like a great idea, in practice, it's a pain in the ass and will
leave people wondering what you were smoking :-)
In summary:
COM
-1
mhash:
sockets:
+1
--Wez.
Ilia Alshanetsky wrote:
COM:
-1. Its core for windows, has little impact on non-windows users other
than a few extra KB to download, and works for the most part.mhash:
sockets:
+1 for both
Rob
Ilia Alshanetsky wrote:
COM:
-0
mhash:
+1
sockets:
+1 for PHP6
Regards,
Michael
Hello Ilia,
-1 (*), +1, +1, but I think you mean 5.3 as we have released 5.2 already
and I think it is a bad idea to drop in bugfix releases.
(*) If someone takes over i am fine with keeping it. I don't like stuff
nobody takes care of. If we cannot maintain it, it mostlikely has issues.
And those issues might be security related. That is very badfor PHP. Now
saying it works for some or most situations doesn't help a tad bit.
best regards
marcus
Friday, December 8, 2006, 5:03:23 PM, you wrote:
This is an exploratory e-mail, so don't panic just yet :-). I am
thinking of moving the COM, mhash and socket extensions to PECL in
5.2 and 6.0 releases and was hoping to hear for & against arguments.
The reason for the making this move are as follows:
COM:
Un-maintained at this time and has a fairly serious number of bugs
(26 by latest count, many of which are crashes)
Only usable to Win32 users, which I think we all admit are a
minority and can always download readily available binaries from
pec4win. Since most of them don't compile the extension from source
anyway there is IMHO little reason to bundle the sources with every
php package.
Moving it to PECL will allow for an independent release cycle, which
may allow for faster fix deployment etc...
I hoping the move will encourage people and/or companies to start
maintaining the extension.
mhash:
Everything this extension that relies on an external lib to do, is
already done by hash extension that is enabled by default and
requires no external libs. There is simply no reason to keep it around.
sockets:
Un-maintained.
Majority of what it can do can already by done via streams in a much
more consistent and stable fashion.
Ilia Alshanetsky
Best regards,
Marcus