Re: [PHP-DEV] libxml bundling

> > I indeed like to see some proof that it is used so widely. You state that > XML is widely used, but I really think that this is only true for a small > part of the people who work with PHP. This does not mean I don't see value > in XML, it's certainly usefull... but that doesn't warrant b

Re: [PHP-DEV] libxml bundling

On Fri, 31 May 2002, brad lafountain wrote: [...] > Why do you feel that bundling is such a burdon and how does it requires more > testing. If libxml release a new release and it is decited to upgrade then > simply upgrade. I don't understand why you think its such a burdon. It looks > like they

Re: [PHP-DEV] libxml bundling

On 3 Jun 2002, Stig S. Bakken wrote: [...] > Such sysadmins have already learnt the usage of --without-xxx options. Sure they do, but it's still annoying for them to see new things enabled-by-default in every new release. Derick --

Re: [PHP-DEV] libxml bundling

On Sat, 2002-06-01 at 02:08, [EMAIL PROTECTED] wrote: > On Sat, 1 Jun 2002, Yasuo Ohgaki wrote: > > [...] > > > I wish it became a default module, too. > > Sure, lets enable everything by default then. ODBC is very important too, > and of course also encryption, so we need mcrypt and mhash, or

Re: [PHP-DEV] libxml bundling

On Sun, 2 Jun 2002, Lukas Schroeder wrote: > instead of modifying ./configure to allow grouping a set of --with{out} > --{en|dis}able into one option (--basic, --bare, ...) i propose setting > up brothers of ./config.nice like > > ./config.bare > ./config.basic > ./config.standard > ./config.ever

Re: [PHP-DEV] libxml bundling

> Andrei solved it. It is because socket_select() mangles the passed arrays > so when you re-enter the call with the mangled $read array you are now > only checking the sockets that happened to trigger the first time through. > > It means you actually have to do: > > $read = array($sock1,$so

Re: [PHP-DEV] libxml bundling

On Sat, Jun 01, 2002 at 04:21:33PM -0400, Dan Kalowsky wrote: > When I state that things shouldn't be enabled by default, it is not > towards making it harder for beginners. I would much rather see PHP > using > something like: > > ./configure --basic > or > ./configure --standard > or some varia

Re: [PHP-DEV] libxml bundling

Why not have a --bare (or equivalent) switch of that kind, to disable literally EVERYTHING that's not mandatory? I believe the issue is that for every 'purist' that cares about bloat, it's safe to say there's more than one user (*) that prefers stuff to 'just work', and not mess with additio

Re: [PHP-DEV] libxml bundling

On Sat, 1 Jun 2002, Zeev Suraski wrote: > I believe there's at least one company that effectively proved that the > opposite is true, there are probably many others. I don't see a problem in > having core technologies enabled by default. Purists can turn them off, > but there are a hell of a lo

Re: [PHP-DEV] libxml bundling

* Sebastian Bergmann wrote: > I don't want to see changes (like those you mention later in your > posting) in PHP to attract new users, but more to bind people that > already use PHP, but are about to "outgrow" it. > > If you (and others) want PHP to stay at the "BASIC for the Web" level

Re: [PHP-DEV] libxml bundling

Zeev Suraski wrote: > It may come to you as a surprise, but there are lots of advanced users > who don't enjoy downloading and building, and prefer to see stuff > working out of the box. I was not adressing the issue this thread is about (bundling 3rd party libraries), but rather Marko

Re: [PHP-DEV] libxml bundling

At 05:05 PM 6/1/2002, Sebastian Bergmann wrote: >Marko Karppinen wrote: > > It seems to me that PHP is increasingly being modeled for a largely > > imaginary audience of purists. I say imaginary because I just can't > > see how droves of purists would've become involved with PHP in the > > first p

Re: [PHP-DEV] libxml bundling

Marko Karppinen wrote: > It seems to me that PHP is increasingly being modeled for a largely > imaginary audience of purists. I say imaginary because I just can't > see how droves of purists would've become involved with PHP in the > first place. I don't want to see changes (like those you men

Re: [PHP-DEV] libxml bundling

Zeev: > I believe there's at least one company that effectively proved that the > opposite is true, there are probably many others. I don't see a problem in > having core technologies enabled by default. Purists can turn them off, > but there are a hell of a lot more average users than there are

Re: [PHP-DEV] libxml bundling

At 02:23 PM 6/1/2002, Christian Stocker wrote: > > If not - I see no problem in always using the bundled library, > > regardless of what's already installed - on the contrary, I see a fairly > > big advantage. > >I see really no advantage in this approach (more memory needed for >example, maybe sy

Re: [PHP-DEV] libxml bundling

On Sat, 1 Jun 2002, Zeev Suraski wrote: > At 12:45 PM 6/1/2002, Christian Stocker wrote: > > > I believe that bundling at the makedist level makes the most sense, > > because: > > > (a) Synchronization is trivial > > > (b) We get to choose what libxml we use, so our libxml-dependent code > > > do

Re: [PHP-DEV] libxml bundling

At 12:45 PM 6/1/2002, Christian Stocker wrote: > > I believe that bundling at the makedist level makes the most sense, > because: > > (a) Synchronization is trivial > > (b) We get to choose what libxml we use, so our libxml-dependent code > > doesn't have to support the zillion different libxml's

Re: [PHP-DEV] libxml bundling

On Sat, 1 Jun 2002, Zeev Suraski wrote: > Guys, > > Unless somebody strongly objects, I suggest we drop the discussion about > how horrible it would be to import libxml2 into our CVS. I believe it's > well established that it's a Bad Thing to do, there's no point hashing it. yep :) > I believe

Re: [PHP-DEV] libxml bundling

Did you conduct a survey about that? I believe there's at least one company that effectively proved that the opposite is true, there are probably many others. I don't see a problem in having core technologies enabled by default. Purists can turn them off, but there are a hell of a lot more a

Re: [PHP-DEV] libxml bundling

Guys, Unless somebody strongly objects, I suggest we drop the discussion about how horrible it would be to import libxml2 into our CVS. I believe it's well established that it's a Bad Thing to do, there's no point hashing it. I believe the question on the table is whether libxml2 is important

Re: [PHP-DEV] libxml bundling

[EMAIL PROTECTED] wrote: > On Sat, 1 Jun 2002, Yasuo Ohgaki wrote: > > [...] > > >>I wish it became a default module, too. > > > Sure, lets enable everything by default then. ODBC is very important too, > and of course also encryption, so we need mcrypt and mhash, or the very > important FT

Re: [PHP-DEV] libxml bundling

On Sat, 1 Jun 2002, Yasuo Ohgaki wrote: [...] > I wish it became a default module, too. Sure, lets enable everything by default then. ODBC is very important too, and of course also encryption, so we need mcrypt and mhash, or the very important FTP and PGSQL extensions. No seriously, I don't

Re: [PHP-DEV] libxml bundling

Hi again > Why do you feel that bundling is such a burdon and how does it requires > more testing. If libxml release a new release and it is decited to > upgrade then simply upgrade. I don't understand why you think its such a > burdon. It looks like they are releasing a version once a month. I d

Re: [PHP-DEV] libxml bundling

> And talk about objective points? Your points don't seem more objective than > mine. Would you localize the symbols in it? What happens if someone loads up another DSO into Apache that also uses libxml? We currently have that headache with expat where someone who uses Apache + PHP + mod_perl h

Re: [PHP-DEV] libxml bundling

First off trimming down means. removing documentation. removing install help. NOT removing any code at all! Why do you feel that bundling is such a burdon and how does it requires more testing. If libxml release a new release and it is decited to upgrade then simply upgrade. I don't understand wh

Re: [PHP-DEV] libxml bundling

At 11:19 PM 5/31/2002, Andi Gutmans wrote: >At 13:12 31/05/2002 -0700, brad lafountain wrote: >>Ok, >> >> I think we are split in two about what to do here. Ill try and list the >>different ideas that have been proposed. >> >>1) don't include at all >> pros: >>No need to worry about auto ins

Re: [PHP-DEV] libxml bundling

Just an overall reply to a point you're making - yes, making the user download and build something if he wants to use XML is really a con, in my opinion. Zeev -- PHP Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] libxml bundling

On Sat, 1 Jun 2002, Yasuo Ohgaki wrote: > > I just want to mention one of the more important reasons why I think > > it's a good idea to include it in the tree. It means that PHP itself and > > its extensions can rely on having the C API present and can add XML > > functionality in various places

Re: [PHP-DEV] libxml bundling

Let's please try to keep the points objective. > 1) don't include at all > pros: >No need to worry about auto install or filesize. > cons: >Forces people to install themselves. Is this really a valid con? This is the standard method of adding functionality to ANY programming language.

Re: [PHP-DEV] libxml bundling

Andi Gutmans wrote: > At 13:12 31/05/2002 -0700, brad lafountain wrote: > >> Ok, >> >> I think we are split in two about what to do here. Ill try and list the >> different ideas that have been proposed. >> >> 1) don't include at all >> pros: >>No need to worry about auto install or filesize

Re: [PHP-DEV] libxml bundling

At 13:12 31/05/2002 -0700, brad lafountain wrote: >Ok, > > I think we are split in two about what to do here. Ill try and list the >different ideas that have been proposed. > >1) don't include at all > pros: >No need to worry about auto install or filesize. > cons: >Forces people to ins

[PHP-DEV] libxml bundling

Ok, I think we are split in two about what to do here. Ill try and list the different ideas that have been proposed. 1) don't include at all pros: No need to worry about auto install or filesize. cons: Forces people to install themselves. 2) trim down libxml and put in cvs pros: Bu