Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:1372 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 23615 invoked from network); 8 May 2003 09:49:07 -0000 Received: from unknown (HELO gamma) (213.150.43.10) by pb1.pair.com with SMTP; 8 May 2003 09:49:07 -0000 Received: from adam by gamma with local (Exim 3.35 #1 (Debian)) id 19Di1H-0000MD-00; Thu, 08 May 2003 11:48:55 +0200 Date: Thu, 8 May 2003 11:48:54 +0200 To: Zeev Suraski Cc: internals@lists.php.net Message-ID: <20030508094854.GA1309@indexdata.com> References: <5.1.0.14.2.20030508112550.04693808@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.1.0.14.2.20030508112550.04693808@localhost> User-Agent: Mutt/1.3.28i Subject: Re: [PHP-DEV] libxml bundling From: adam@indexdata.dk (Adam Dickmeiss) On Thu, May 08, 2003 at 11:34:15AM +0300, Zeev Suraski wrote: > At 01:17 07/05/2003, Edin Kadribasic wrote: > >Sterling, > > > >You have just added 3.5 MB of source into the PHP code tree despite your > >assurances that libxml was only "slightly" bigger than expat which takes > >up "only" 432 KB. > > > >This is IMHO completely unnecessary as libxml comes preinstalled as a > >shared library on most modern Unix systems and because it adds bloat to > >PHP distribution. > > Our target audience is not just modern Unix systems. And with all due > respect to modern Unix systems, the versioning hell they're going to is > pretty similar to the way Windows looked like circa 1992, which means that > if we're relying on existing libraries, we're begging for trouble. > I see the seconding and thirding and fourthing of this message, but I still > fail to understand why people consider the nuance of increasing the package > size, something that's completely insignificant for almost all of our > users, as a too high a price for keeping PHP on top of the recent > technologies. Good XML handling is as basic as good forms handling in this > day and age. I don't worry about the bundling size, really. What I worry about is having multiple versions of a library on a system. For example, I once got VERY confused because I had a PHP module as well as another Apache module using the "same" library, which wasnt't the same. One of them was using a shared library; one was statically linked.. The system would call "randomly" depening on the order in which Apache forked and used one of the two modules. Very confusing. Very wrong. There is a run time penaly of having two relatively big SO's too. libxml/libxml2 is a fairly big one. Would PHP maintainers, then update their CVS once in a while to reflect the newest updaes? Seems like the wrong thing to me. And wrong on Windows too.. We too ship YAZ as both windows and Unix and is now using libxml2. I would never bundle the source with that. However, what we do bundle is the libxml dll (and iconv) on Windows. Bundling _may_ be good for binary dists. Not for source unless the circumstances are very special (licensing, etc.). libxml has a licence that works with PHP and it's so widely available. The next step is that people will bundle GNU libc. -- Adam > Zeev > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php -- Adam Dickmeiss mailto:adam@indexdata.dk http://www.indexdata.dk Index Data T: +45 33410100 Mob.: 212 212 66