ilia

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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

sb

+1

--
Sebastian Bergmann http://sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

antony

+1 +1 +1

--
Wbr,
Antony Dovgal

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

stas

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.


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


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/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

ilia

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.

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.

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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

stas

I meant runtime resources, not developer resources. Like memory, CPU, etc


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.

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/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

andi

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


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

pierre.php

Hello,

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.

It is possible without moving it out. It could even be a good thing to do it.

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.

We may move it from php 6.0 and up or at least from 5.3.0.

+1 from php 6.0 and up but I'm worrying a bit about 5.x code relying on it.

--Pierre

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

derick

-1, but we need somebody to have a look at the issues there.

-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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

zeev

Same as Derick and Stas.

Zeev

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php