Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:22961
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <444E4262.8050501@mysql.com>
Date: Tue, 25 Apr 2006 18:38:10 +0300
Organization: MySQL AB
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2) Gecko/20050219
MIME-Version: 1.0
To: Steph Fox <steph@zend.com>
CC: internals <internals@lists.php.net>
References: <444D475B.1060200@zend.com> <003601c66839$a92ea9b0$6602a8c0@foxbox> <4e89b4260604250758h5588d1abk1fd4a72dfc1b29d4@mail.gmail.com> <015c01c66882$9284ed20$6602a8c0@foxbox> <017201c66886$3a3d2570$6602a8c0@foxbox>
In-Reply-To: <017201c66886$3a3d2570$6602a8c0@foxbox>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] more candidates for PECL
From: andrey@mysql.com (Andrey Hristov)

   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