Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:22960
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <017201c66886$3a3d2570$6602a8c0@foxbox>
Reply-To: "Steph Fox" <steph@zend.com>
To: "Wez Furlong" <kingwez@gmail.com>
Cc: "Antony Dovgal" <antony@zend.com>,
	"internals" <internals@lists.php.net>
References: <444D475B.1060200@zend.com> <003601c66839$a92ea9b0$6602a8c0@foxbox> <4e89b4260604250758h5588d1abk1fd4a72dfc1b29d4@mail.gmail.com> <015c01c66882$9284ed20$6602a8c0@foxbox>
Date: Tue, 25 Apr 2006 18:35:12 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="Windows-1252";
	reply-type=response
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] more candidates for PECL
From: steph@zend.com ("Steph Fox")

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