more candidates for PECL View as Markdown

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

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

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

ext/skeleton is a different beast and I suspect that 99.99% users have
never heard of it.

You mean you only want to move things people have heard of?!

I mean I only want to move things which I consider unsafe.
It's safe to include ext/skeleton as you definitely know what you're doing
when you use it.

Ah now, you're looking at things from a very different perspective. I'm
looking from the pov that pretty much everything eventually should be in
PECL. The exceptions ought to be pretty much the stuff that is currently
bundled and enabled by default, plus ext/pdo (but not the PDO drivers).
Since everything else has to be enabled anyway, what's the difference to the
end user whether it comes via PECL or as part of the PHP distribution?

• Steph

Hi Steph,
Steph Fox wrote:

Hi Wez,

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.

Since when have existing books been a reason not to change something?

recall why ext/mysqli uses underscores instead of suckyCaps.

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.

I can't see any positive ones :)

The scenario as I understand it should be that everything goes into PECL
unless it's essentially part of PHP, ergo people aren't likely to be
confused about where to find whatever they're looking for. I can't see
how moving ext/skeleton to PECL conflicts with that approach, unless you
take the view that the template is essentially part of PHP itself?

It'd be good to have Hartmut's view on that, since he wrote both those
systems.

By the way, at present PHP for win32 ships without any de facto database
support (unless you count ODBC, which doesn't currently have an active
maintainer dedicated to it and should probably be in PECL too). I think
the *nix-based devs tend to forget that we don't have ext/sqlite enabled
by default under Windows any more, and can't do so unless ext/pdo is...
there are better arguments than this for having ext/pdo enabled by
default, not the least being that it would make it a one-step process to
install a PDO driver. Is there any reason it isn't?

• Steph

Andrey

--
Andrey Hristov, Software Developer
MySQL AB, www.mysql.com
Walldorf, Germany

Are you MySQL certified? www.mysql.com/certification

Hi Wez,

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.

Since when have existing books been a reason not to change something?

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.

I can't see any positive ones :)

It provides a basic template for making new extensions without having
to go searching through PECL, this is a big + IMHO.

Ilia Alshanetsky
Advanced Internet Designs Inc.
ilia@prohost.org

Since when have existing books been a reason not to change something?

Given the lack of documentation on this topic and the fact that
ext_skel and ext/skeleton are pretty much just plain text, I think
it's a pretty damned good reason.

I can't see any negative points to keeping ext/skeleton in the tree.

I can't see any positive ones :)

That's because you don't use it.
I use ext_skel a lot. I'm fairly sure that most extension authors
also start with ext_skel.

the view that the template is essentially part of PHP itself?

yes.

It'd be good to have Hartmut's view on that, since he wrote both those
systems.

I suspect that Hartmut will want to keep at least one of them around
in the core.

.. the least being that it would make it a one-step process to install a PDO
driver. Is there any reason it isn't?

You just turn it on in the php.ini file (we ship the DLLs).
That's "one-step", right?
It's a gazillion times easier than unix.

--Wez.