# more candidates for PECL

- Thread: https://externals.io/message/22938
- Original archive: https://news-web.php.net/php.internals/22938
- Started by Antony Dovgal on 2006-04-24T21:47:07+00:00
- Messages: 16
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #22938 — Antony Dovgal — 2006-04-24T21:47:07+00:00

URL: https://externals.io/message/22938#22938

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

---

## #22941 — Richard Lynch — 2006-04-25T05:11:43+00:00

URL: https://externals.io/message/22938#22941 · In reply to: #22938

> 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

---

## #22946 — Antony Dovgal — 2006-04-25T07:09:20+00:00

URL: https://externals.io/message/22938#22946 · In reply to: #22945

> 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

---

## #22945 — Steph Fox — 2006-04-25T07:27:06+00:00

URL: https://externals.io/message/22938#22945 · In reply to: #22938

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

---

## #22949 — Michael Wallner — 2006-04-25T08:06:23+00:00

URL: https://externals.io/message/22938#22949 · In reply to: #22938

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

---

## #22950 — Antony Dovgal — 2006-04-25T08:37:57+00:00

URL: https://externals.io/message/22938#22950

> > […]
> 
> 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.

-- 
Wbr, 
Antony Dovgal

---

## #22951 — Steph Fox — 2006-04-25T09:49:59+00:00

URL: https://externals.io/message/22938#22951 · In reply to: #22950

> > […]
>
> 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

---

## #22959 — Wez Furlong — 2006-04-25T14:58:55+00:00

URL: https://externals.io/message/22938#22959 · In reply to: #22945

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.


> 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
>
>
> > […]

---

## #22961 — Andrey Hristov — 2006-04-25T15:38:10+00:00

URL: https://externals.io/message/22938#22961 · In reply to: #22960

Hi Steph,
Steph Fox wrote:
> Hi Wez,
> 
> > […]
> 
> 
> Since when have existing books been a reason not to change something?
>

recall why ext/mysqli uses underscores instead of suckyCaps.

> > […]
> 
> 
> 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

---

## #22960 — Steph Fox — 2006-04-25T16:35:12+00:00

URL: https://externals.io/message/22938#22960

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

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

---

## #22972 — Ilia Alshanetsky — 2006-04-26T15:46:51+00:00

URL: https://externals.io/message/22938#22972 · In reply to: #22960

> Hi Wez,
>
> > […]
>
> Since when have existing books been a reason not to change something?
>
> > […]
>
> 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

---

## #22974 — Steph Fox — 2006-04-26T17:09:33+00:00

URL: https://externals.io/message/22938#22974 · In reply to: #22972

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

OK, fair enough. Is anyone going to answer the rather more important 
question of whether/when ext/pdo is going to be enabled by default? In 5_1 
branch not having pdo enabled by default means Windows users can't have 
ext/sqlite by default either, and I think everyone else tends to forget this 
and assume all PHP versions have a database to hand. (Witness what Tony said 
with regard to filepro.)

- Steph

---

## #22975 — Wez Furlong — 2006-04-26T18:47:42+00:00

URL: https://externals.io/message/22938#22975 · In reply to: #22960

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

---

## #22977 — Derick Rethans — 2006-04-26T19:15:41+00:00

URL: https://externals.io/message/22938#22977 · In reply to: #22959

> 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

---

## #23013 — Steph Fox — 2006-04-28T19:19:22+00:00

URL: https://externals.io/message/22938#23013

Hi Wez,

> > […]
>
> 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.

Yes, and strangely enough that does include me.

I thought this thread ended three days ago :) It seems everyone on the dev 
team wants to keep ext/skeleton in the core, I'm not going to argue with 
y'all over it.

<snip />

> > […]
>
> You just turn it on in the php.ini file (we ship the DLLs).

I know. I've even been responsible for shipping those DLLs before now, 
remember? I don't understand what the problem is here.

> That's "one-step", right?

No, it isn't. You need to have PDO 'turned on' before you can have SQLite 
enabled under doze. That's not only not "one-step", it's also fairly "wtf".

> It's a gazillion times easier than unix.

Erm, under *nix sqlite is enabled by default....!

- Steph

---

## #23023 — Hartmut Holzgraefe — 2006-04-29T10:00:55+00:00

URL: https://externals.io/message/22938#23023 · In reply to: #22975

Wez Furlong wrote:
> > […]
> 
> I suspect that Hartmut will want to keep at least one of them around
> in the core.

*DISCLAIMER*

I did *not* write ext_skel, i tried to maintain it for a short while
but gave up on that pretty soon ...

pecl-gen should be ext_skel compatible (i haven't checked this for
quite a while though)

i don't mind whether it stays or not, i haven't used it for years now

whether pecl-gen is more maintainable is quite arguable thow ;)
(although at least it does not depend on arcane tools like awk ...)

-- 
Hartmut Holzgraefe, Senior Support Engineer                            .
MySQL AB, www.mysql.com

Are you certified? http://www.mysql.com/training/certification