Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » more candidates for PECL »

more candidates for PECL

php.internals

Antony Dovgal

20 years ago
Hello all. I'd like to propose yet another bunch of extensions to be moved from core to PECL. (Don't worry, this is for 5.2 and HEAD. 5.1 is untouchable atm). They are: ext/hwapi --------- Bugs: 7 bug reports. All bogus. Status: unmaintained I've never heard of Hyperwave and I can hardly believe there is at least one person on the planet who uses this module. No idea why do we include it in the core. ext/filepro ----------- Bugs: 1 bug report. Take a look at it, it's really useful: http://bugs.php.net/bug.php?id=12102 Status: unmaintained Looks like filePro is some kind of pseudo-DB based on files. At least this is what Wikipedia says. Is it really necessary to support it IN THE CORE along with SQLite? ext/recode ---------- Bugs: 10 bug reports. All of them were created in old good times of PHP 3.0b3. Status: maintained (though, I can see from the CVS log that it was changed last time ~5 years ago, excluding "bump year" and other minor changes). And btw, it's known to break ext/mysql build. I've no idea why do we need yet another unsupported and not recommended way to do what ICONV does. --------------------------------------------- Ok, basically this is it. But not really... I would like to make one more proposal: Lets move ALL unsupported/unmaintained/unused extensions to Sibe^H^H^H^H PECL. Yes, I know that "people rely on them being in the core.. blah-blah-blah". That's great. And that'll help us to find maintainers for the code. Or at least will bring some attention to the problem of core extensions (aka "known to be stable"), which are not even maintained for years. I believe nobody actually uses them because of that - take a look at ext/snmp, for example. A bunch of poorly named (naming standards, eh?) _undocumented_ functions... Oh, and the implementation is also.. weird. Not sure if it's possible to move SAPIs to PECL, but having 9 (yes, NINE) unmaintained/unsupported SAPIs sounds like a bit overkill to me. (aolserver, apache_hooks, caudium, continuity, milter, phttpd, pi3web, roxen, tux - yup, nine..)
-- Wbr, Antony Dovgal

Richard Lynch

20 years ago
On Mon, April 24, 2006 4:47 pm, Antony Dovgal wrote:
> I'd like to propose yet another bunch of extensions to be moved from > core to PECL. > (Don't worry, this is for 5.2 and HEAD. 5.1 is untouchable atm).
This naive reader thinks it should be targeted at 6.0 release, as it seems like pretty major changes to me... There might not be anybody using Hyperwave, and the other extensions you specifically named are probably not actively used since they are broken. But the odds are pretty good that somebody somewhere has legacy code that is still using something that's in your criteria/list, and is going to be affected by "missing" functionality from 5.1 to 5.2 There's also the possibility that moving all that stuff could have unforeseen results -- the kind of bug/issue that takes a long time to detect, much less correct. "You can't change just one thing" I'm agreeing 100% to move it out of core and into PECL! I just think the timing should be on a major release (6.0) and not a minor one (5.x) since the changes to code-base seem rather large and wide-sweeping, even if the functionality and userbase are believed to be negligible. Why tick off that one developer by "removing" functionality in an upgrade, when that's only supposed to happen in a major release? jmho
-- Like Music? http://l-i-e.com/artists.htm

Mike Bretz

20 years ago
Can we add a notice into the configure script in 5.x when using these extensions and move them into PECL for 6.0? A hint in 5.x will inform the few people who are using the extensions that they will find them in PECL in future. Maybe current configure options like "--with-hwapi" will be kept and print an error message about moved extension. This would help those people, who take old configuration options to recompile new version. mike Richard Lynch wrote:
> On Mon, April 24, 2006 4:47 pm, Antony Dovgal wrote: > >> I'd like to propose yet another bunch of extensions to be moved from >> core to PECL. >> (Don't worry, this is for 5.2 and HEAD. 5.1 is untouchable atm). >> > > I just think the timing should be on a major release (6.0) and not a > minor one (5.x) since the changes to code-base seem rather large and > wide-sweeping, even if the functionality and userbase are believed to > be negligible. > > Why tick off that one developer by "removing" functionality in an > upgrade, when that's only supposed to happen in a major release? > > jmho > >
-- mike peter bretz metropolis ag / entwicklung email: m.bretz@metropolis-ag.de heinestraße 72 phone: +49-7121-348-120 d-72762 reutlingen fax: +49-7121-348-111 http://www.metropolis-ag.de/ metropolis ag. creating social internetworks.

Steph

20 years ago
I'd add ext/skeleton to that list. Hartmut's PECL_gen project is way ahead of it, actively supported and very easy to get hold of... and Hartmut gives it a <shameless plug> at every opportunity :) - Steph

Antony Dovgal

20 years ago
On 25.04.2006 11:27, Steph Fox wrote:
> I'd add ext/skeleton to that list. Hartmut's PECL_gen project is way ahead > of it, actively supported and very easy to get hold of... and Hartmut gives > it a <shameless plug> at every opportunity :)
ext/skeleton is a different beast and I suspect that 99.99% users have never heard of it.
-- Wbr, Antony Dovgal

Wez Furlong

20 years ago
The problem with moving ext/skeleton is that we'll end up shipping PHP without an extension template of any kind. Almost every single PHP book that talks about writing extensions uses ext_skel to do so. Giving PECL_gen some good press is a different issue, and does not require that we move ext/skeleton or ext_skel. I can't see any negative points to keeping ext/skeleton in the tree. --Wez. On 4/25/06, Steph Fox <steph@zend.com> wrote:

Derick Rethans

20 years ago
On Tue, 25 Apr 2006, Wez Furlong wrote:
> The problem with moving ext/skeleton is that we'll end up shipping PHP > without an extension template of any kind. Almost every single PHP > book that talks about writing extensions uses ext_skel to do so. > > Giving PECL_gen some good press is a different issue, and does not > require that we move ext/skeleton or ext_skel. > > I can't see any negative points to keeping ext/skeleton in the tree.
Yeah, I want to keep that too. Derick
-- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org

Michael Wallner

20 years ago
Antony Dovgal wrote:
> Hello all. > > I'd like to propose yet another bunch of extensions to be moved from > core to PECL. > (Don't worry, this is for 5.2 and HEAD. 5.1 is untouchable atm). > > They are: > > ext/hwapi > ext/filepro > ext/recode > > I would like to make one more proposal: Lets move ALL > unsupported/unmaintained/unused extensions to Sibe^H^H^H^H PECL.
While I don't like this analogy, I fully agree with you. Regards,
-- Michael - <mike(@)php.net> http://dev.iworks.at/ext-http/http-functions.html.gz