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 <[EMAIL PROTECTED]> 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 :) > > - Steph > > > > 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 > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: http://www.php.net/unsub.php > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
