Re: Something about PEAR policy

On Sat, Jul 21, 2001 at 03:45:54PM -0400, nathan r. hruby wrote: > > I don't think anyone is objecting to the inclusion of PEAR-ified > > PHPLIB components. The only outstanding issue is for someone to > > actually do the work (i.e. convert them to the established PEAR > > standards). > > That would be wonderful in the end. There are a few practical problems > with that line of thinking though. Specficily, what about everyone who > depends on the exsisting PHPLib API? For those cases, the existing PHPLIB distribution still exists. There's no need to break the API. I can understand why you get that impression, but I'm not so strict as to call for the renaming of the functions just to "conform". I would like to see PHPDoc comments added, for example, because I think all PEAR classes should be able to be run through PHPDoc in order for them to produce API documentation. I would also like to see the code organized into a PEAR package (package.xml). There are also additional PEAR standards that require the code to work with as many permutations of INI options as possible, and I know a lot of existing code doesn't meet that requirement. None of that would break the existing code, but it would require work for it to meet PEAR standards. > > I believe the original "problem" (at least, from my viewpoint) > > was that some people wanted to import PHPLIB wholesale (without > > conversion) into the PEAR cvs tree. I argued for their > > separation into individual components (e.g. 'template', 'auth'), > > but, once again, no one has done to work. > > Yes, but that breaks all of the PHPLib API. Good for PEAR, bad for evey > person and app using PHPLib -- hence the notion of a wholesale import of > PHPLib as an App Framework with the understanding of a gradual > PEAR-ification of the API, or something to that effect (a wrapper class, > etc..), as it would allow a gradual process for phplib users and a better > porting process for PEAR, allowing the classes to be not only ported but > improved upon as well with the PEAR community's input and suggestions. I still think breaking PHPLIB into components is ultimately the way to go. With PHPLIB now, it's pretty much all or nothing (unless you start modifying 'local.inc' and company, and that doesn't fit into PEAR's "packaging" mentality. > Again, that kind of thinking [just components] is what I mean when I say > "insular pratices." It offers PHPLib (or BinaryCloud or phpSlash, etc..) > no incentive to port over to PEAR becasue there is little flexibility to > make people other than PEAR users / developers happy. It seems that it's > PEAR's way or the highway. No, I don't view it that way at all. I view PEAR as a vehicle for provided a (somewhat) standardized set of classes and components. Right now, there is a wealth of PHP code out there, all written in its own way. There are also a lot of people that feel that all of that code should be imported into PEAR wholesale. From that perspective, it seems that the logical thing to do is make PEAR as open as possible to all sorts of submissions. While I agree that that perspective has a lot of merits, I diverge slightly from it in viewing PEAR as an opportunity to standardize a group of code, neatly packaged for end users and developers. This will help maintain a standard of quality (not that the existing code isn't of quality, but there's no existing metric by which to measure such code). > This is all further complicated by the fac that PEAR's way is a constanly > moving and amorphus target to which few people can divine. Agreed. I plan on spending a good hunk of time on getting PEAR off the ground so that there's a more concrete foundation on which to build. Details to follow if everything works out for me. > I don't really want to sound mean and I'm not trying to start a flame war, > but really, there are some implementation problems with PEAR that haven't > gone away and make it hard for others to extend and contribute. In time > that will all pass. No, of course. Everyone's comments are entirely welcome, especially at this fledgling stage of PEAR. > All I really want is for phplib to continue doing it's own thing until > such time that all of these question can be answered (and documented) for > all and they are upheld over time. That won't happen in a day, or a > weekend or a month, and as such phplib needs to be continued in > development. Agreed, and I hope that day isn't too distant. -- Jon Parise (jon@csh.rit.edu) . Rochester Inst. of Technology http://www.csh.rit.edu/~jon/ : Computer Science House Member