split of pear for users and pear for developers

Hi, When the split of the pear command happens (i.e. pear for users will allow install/uninstall/revert/download/list/etc. and pear for developers also allows packaging commands), I'd like to suggest a few additions to the packager portion. One would be a command that auto-generates a simple package.xml-generation script based on PEAR_PackageFileManager (if it is installed), to help new users get started with PEAR. All they would need to do is specify a location and then they could start testing the application from an installed location very easily, and hand-edit the generated script. The other would be a split of the package name validation from a simple method into a class as suggested by Sandro and others - this will be extremely important for the packaging mechanism. In general, I would like to see all of the PEAR-specific things branched off into self-contained sub-units/subpackages. For instance, it should be possible in the future to specify a different packaging engine through configuration, as well as a different package name validator. This will allow some more advanced things that we haven't thought of now to happen without any need for future refactoring. In other words, the PEAR core should have a well-defined API and expect itself to be extended in the future, perhaps with advanced subpackages for people who wish to add on functionality like ZZOSS has. This will also simplify questions such as how to handle PECL differently from PEAR. All of the builder code in the installer seems out of place right now. We also desperately need a way to automatically install pre-compiled PECL extensions on windows, which will be a hack with the existing installer, but with plugin modules, it would not need to be. Greg