Re: temporary solution

Hi Greg, I've been following this debate in the PEAR mailinglist for a while, and I for one think that it is okay to break BC. Why? Well first of all, applications relying on PEAR 1.3 has probably already been written, and fixes for 1.3 packages could still be made. Second: Future applications being written (and i pressume those would be based on PEAR 1.4 application framework) should not be burdened by BC. Also PHP5 is only slowly implemented by hosting companies (at least in Denmark), swithing to PHP5 requiring PEAR 1.4 could facilitate a swifter upgrade policy. I'm telling you because I think it's vital for PEAR to have a set of methods that allows you to easily upgrade your own code-repositories. I see this feature as the most important feature of PEAR, and you have done a lot of impressive work on it so far. in awe and kind regards :-) Lars On Sun, 06 Mar 2005 17:21:51 -0500, Greg Beaver <cellog@php.net> wrote: > I'll tell you how all the memory issues and everything else is going to > be solved. > > I have a bit of a forced vacation from tonight until Friday, as my > quartet will be doing an intense residency in Connecticut working in > schools. I may have some email access in the hotel, or none at all. > Won't know until I get there. > > Vacation for me will help a lot. If others want to look at solutions, > be my guest. > > I want to state for the record: > > I did not implement *anything* that I saw as superfluous, and at several > points dropped features. Every solution is designed either to maintain > BC (something that was 100% successful so far), or to solve a major > application-related problem. > > PEAR 1.3.x is very good at very little. You can use it to install a few > pecl extensions on unix only (most of them don't work most of the time), > to install PEAR packages and a few other trivial scripts. It works > great at these things. It is absolutely HORRIBLE for: > > 1) distributed anything > 2) dependencies of any complexity beyond "package A uses package B" - > look at SOAP for a perfect example of something PEAR 1.3.x does not > handle well at all. SOAP isn't even that complex, it's only 3 levels > deep of 1:1 required dependencies! > 3) any application support whatsoever. role="php", data, test, whatever > is just not good enough for anything that has to run out of a document root. > 4) PECL extensions on windows > > Now, if you don't need any of these things, then PEAR works just fine. > Clearly, some people do need these things, and I'm betting my > programmer's club pin on the fact that there are more of them than there > are current PEAR users. A *lot* more of them. How do I know this? A > heck of a lot more people are using applications than are using PEAR. > PEAR is still a fringe project compared to the major programs out there > like phpMyAdmin and so on. > > There is one thing I coded that can probably be lazy-loaded, and that is > the stuff for generating a package.xml and to a certain extent for > validating the package.xml. This will only save about 1 MB, which is > not nearly enough for Alan's goal of matching what 1.3.x did. > > No, channels can't be optional in any circumstance, it would require a > 100% redesign and another year to 1.5 year delay to get it stable. > > The only way to drop memory usage properly is to follow Mozilla's route > and completely break BC. > > 1) no support of package.xml 1.0 whatsoever > 2) no support of PHP 4 > 3) no support for the existing registry format. > > This will allow a ton of the weight to be shouldered by the xml stuff > built into php 5, and would drop PEAR back into the 3-4 MB range easily. > > PEAR 1.x is caught between a rock and a tight spot - you can have either > features or memory savings. Which is it going to be? > > Greg > > -- > PEAR Development Mailing List (http://pear.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > -- Address: Lars Jensen Lersoe Parkallé 53, 1th DK-2100 Copenhagen Denmark GSM: (+45) 20 84 79 28 Email: lars.jensen@exenova.dk