temporary solution

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