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