Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:2253 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 13740 invoked from network); 9 Jun 2003 14:16:32 -0000 Received: from unknown (HELO 23i.net) (216.127.66.132) by pb1.pair.com with SMTP; 9 Jun 2003 14:16:32 -0000 Received: (qmail 6929 invoked from network); 9 Jun 2003 14:16:33 -0000 Received: from unknown (HELO aragorn) (81.98.223.212) by frodo.23i.net with SMTP; 9 Jun 2003 14:16:33 -0000 To: Cc: "Joe Orton" Date: Mon, 9 Jun 2003 15:16:30 +0100 Message-ID: <003601c32e91$b9d3d8b0$0200a8c0@23i.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Subject: Why Move to PECL? From: james@imajes.info ("James Cox") Thinking a bit about this topic, I thought I'd pen some thoughts as to = why bother moving to PECL in the first place, just to put things into perspective. As an extension developer, PECL provides the following: -- your own release cycles. =20 -- granular package management : want to be the only maintainer? Fine, = this is no problem with PECL. As well as the other sourceforge-esque things = that will come as people request them. As an end user (and dev), PECL provides the following: -- easier install path. (# pear install foo) -- no need to recompile... Useful in hosting environments where you may have chrooted apache/php.. This doesn't sound like much, however I think it's quite substantial, as = it allows extension developers to provide different release cycles to the = main php core.=20 What does that mean for the PHP RM?=20 =20 -- less QA hassle. The only releases that would get sent out via a PHP = RM would be --STABLE.tgz -- or in other words, packages that would have had, theoretically, a substantial amount of QA already, and = so would require less attention from the PHP RM. That means that QA can = focus on core language issues.=20 -- smaller packages. We can provide php-lite, php-all, php-common = packages. Php-lite would just incorporate the main core of php, and the pear/pecl tools. Php-all would be a complete bundle, with suggested libraries included, and php-common would be like php.ini-recommended. How do we get here? By moving PECL into the limelight. This week, I will be splitting PECL = into it's own cvs module, and (after discussion) I'd like to create a version = of pearweb for pecl.php.net, essentially seperating the PEAR and PECL = projects. We can then start an upgrade path of getting packages into PECL. I am = pretty sure that doing this kind of stuff will make life easier for our downstream users (ie, cc'ed Joe Orton, who packages RPMs for RedHat) as = they more or less do this _already_ anyhow. We will (hopefully) make it = easier for them so they can remove their hacks to do this. I think the feeling of throwing everything into PECL right now is = probably flawed; as Rasmus said, we are at risk of forcing it to be something = it's not right now, and I think this contravenes Stig's excellent management = of PEAR (ie, do it right, don't hack it). So, the summary:=20 Lets promote PECL somewhat. Lets make it work without all the minor = problems right now (eg, secure binaries, win32 support, etc etc). Then once we = are all using that instead of recompiles every time.. (which won't take = long) moving to PECL becomes a natural progression. -- james -- James Cox :: james@imajes.info :: http://imajes.info/=20 Was I helpful? = http://www.amazon.co.uk/exec/obidos/wishlist/23IVGHQ61RJGO/ The mind leads, the emotions follow. - Ayn Rand