Everything

php

Home » Project » Newsgroups » php.internals » Moving COM, Socket & mhash to PECL »

Moving COM, Socket & mhash to PECL

php.internals

Ilia A.

19 years ago

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

Sebastian Bergmann

19 years ago

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

Antony Dovgal

19 years ago

On 12/08/2006 07:03 PM, Ilia Alshanetsky wrote:

> COM:
> mhash:
> sockets:

+1 +1 +1

--
Wbr,
Antony Dovgal

Stanislav Malyshev

19 years ago

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

Ilia A.

19 years ago

On 8-Dec-06, at 1:01 PM, Stanislav Malyshev wrote:

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

Stanislav Malyshev

19 years ago

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

Johannes Schlueter

19 years ago

Hi,

On Fri, 2006-12-08 at 13:17 -0500, Ilia Alshanetsky wrote:

> On 8-Dec-06, at 1:01 PM, Stanislav Malyshev wrote:
>
> >> 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

Edin Kadribasic

19 years ago

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

Andi Gutmans

19 years ago

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

Wez Furlong

19 years ago

On 12/8/06, Andi Gutmans <andi@zend.com> 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.

Andy Wharmby

19 years ago

Wez Furlong wrote:

> On 12/8/06, Andi Gutmans <andi@zend.com> 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

Antony Dovgal

19 years ago

On 12/20/2006 12:26 PM, Andy Wharmby wrote:

> 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

Pierre Joye

19 years ago

Hello,

On 12/8/06, Ilia Alshanetsky <ilia@prohost.org> 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)

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, which
> may 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 start
> maintaining 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

Derick Rethans

19 years ago

On Fri, 8 Dec 2006, Ilia Alshanetsky 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.

regards,
Derick

Zeev Suraski

19 years ago

At 21:51 08/12/2006, Derick Rethans wrote:

>On Fri, 8 Dec 2006, Ilia Alshanetsky 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

Richard Lynch

19 years ago

On Fri, December 8, 2006 10:03 am, Ilia Alshanetsky wrote:

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

Wez Furlong

19 years ago

On 12/8/06, Ilia Alshanetsky <ilia@prohost.org> wrote:

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

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.

Rob Richards

19 years ago

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

Michael Wallner

19 years ago

Ilia Alshanetsky wrote:

> COM:

-0

> mhash:

+1

> sockets:

+1 for PHP6

Regards,

--
Michael

Marcus Börger

19 years ago

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