Re: PEAR a way forward

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Oct 4, 2006, at 12:58 PM, Joshua Eichorn wrote:

I believe that PEAR is a turning point, both in it's organization and development, and in it's continued position as a leader in the php developer community. [ snip ] I could not agree more. With every new PHP release, the core of PEAR is marginalized further, in that it's functionality is being implemented in PHP itself. It's clear to me that PEAR simply cannot proceed in the way we have in the past.

PEAR has never had a written goal. Instead the many developers simply followed their own paths with their own agendas, but this means PEAR doesn't have the momentum and power that a single mission statement would provide. The idea of open source is many people working together to create a superior project, a project that is greater then what any one person could create on their own. What I propose is a new goal for PEAR implemented along side our upgrades to the website an infrastructure. I think that pear needs to move forward, pushing the limits of what PHP can do while providing solid, forward looking classes for use in any php application. Pear should try to be the base that php developers can stand on, while also providing niche classes that do really cool things. I concur. I feel that PEAR should be, predominantly, a platform for the development and deployment of PHP libraries and applications.

While I agree with most of the broad strokes of your proposal, I feel that a site redesign should be a secondary concern, and that the code is what will make or break PEAR in the era of PHP 5 and beyond. To summarize my suggestions from earlier today, I feel that, in terms of code, we should: - - Focus on the installer, and making it the #1 way to develop and deploy PHP code of any sort. To this end, I feel that the following tools would be extremely useful: = Subversion support, i.e. "pear svntag" = Some sort of front-end for creating and managing package.xml files. = Improved documentation (or tools) to make the more complex features (bundles, subpackages, custom roles) more accessible. = Ideally, implement a way to deploy an entire application with no more than "pear install MySite-1.0.0.tgz". - - Dump the current PEAR class. - - Implement a standard configuration / load / initialization system which abstracts the class names and paths. - - Make setting up a PEAR channel a task simple enough that anyone can do it, so as to foster third party code libraries and applications. - - Create compelling packages which build on the functionality in current PHP version, instead of duplicating it. For example: = A database class which provides convenience for PDO, but lets PDO handle the heavy lifting and ugly details. = A new form class which builds on DOMDocument, has sane group handling and improved rendering. In general, I think that most of the packages which deal with XML / HTML should be reimplemented to extend from DOMDocument. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFFJCO9xuUdPD6j2IMRAvo5AKDPtc57mbrdSU38yetYRaRwpL0sugCgsc/c BlrDoJNGpj4FxdBVaUgi31w= =ORIB -----END PGP SIGNATURE-----