request for testers, new PEAR core code

Hi all, In the continuous quest to make the PEAR core splendid, I just committed some experimental code, and would like some cursory testing before unit tests are written. Before anyone's heart stops, don't worry, there is no way it could accidentally overwrite any existing or old code. I exclusively added new files that can be removed at any point in the future. To test it, check out HEAD of php-src/pear and run: $ pear upgrade package-PEAR-new-Downloader.xml Fortunately, any bugs you might encounter won't affect your ability to revert this with: $ pear upgrade --force package-PEAR.xml which will return you to 1.3b3. You can also easily do $ pear upgrade --force PEAR-1.3b1 or whatever version you were using, and that will work. Basically, the code is a reshuffling - the functionality should be identical to the enduser. However, anyone who had extended PEAR_Installer::download() or used it in a class would experience a rather severe BC break, as the entire functionality has been moved out of PEAR_Installer into a new class, PEAR_Downloader. This is in preparation for an eventual move to new ways of grabbing packages (local repositories or whatnot). A quick glance at the source will reveal a tremendous improvement in readability and testability, as methods are no longer 400 lines long, and none are longer than 100 lines. Functionality has been better encapsulated, and long parameter lists have been chopped down to the minimum needed for a particular method. In addition, the Installer now does what it advertises: installs. Nothing else. Basic good OO principles :). In any case, since the code is experimental, there is plenty of time to snipe at it and find improvements I missed. When it stabilizes, I'll simply merge it with the code, and we'll be in business. The question is whether to do that before version 2.0, as the Installer code changes significantly. A possible fix might be to make PEAR_Installer extend PEAR_Downloader, and have wrapper methods that encapsulate the new functionality. This would be easy to code, with minimal overhead. Regards, Greg