RE: [PHP-PEAR] PHPLib - Pear merge project on SF approved

Paul, not a problem... :) > -----Original Message----- > From: Paul Meagher [mailto:paul@datavore.com] > Sent: Thursday, March 08, 2001 9:01 AM > To: jstuart-php@neo.rr.com; Php-Pear > Subject: Re: [PHP-PEAR] PHPLib - Pear merge project on SF approved > > > Jeff, > > Thanks for taking the intiative on this. > > > > Ok.. The Pear/PHPLib merge project has been approved on Source Forge... > this > > will be used for doing the following steps. > > > > 1) Create a Pear::PHPLib Class. > > I just joined the effort. Not sure what you mean by this step. Great! What I mean basically is create a directory in the pear "CVS" (on the SF repository above) that is called PHPLib and then basically (this is step 2), copy the PHPLib code into it. > > > 2) Underneath that, import ALL of the PHPLib classes into it. > > Which ones? Stable or experimental ones? I haven't had much success with > getting the newest PHPLIB db stuff to work. I think it is currently broken > with the hope that someone was going to unbreak it. Has anyone gotten the > experimental db classes to work? > > I am afraid that this step may require that you actually put together a > phplib4 distro and start working from that? It would be good to have a > PHPLIB core developer to help us decide which classes should be moved under > here. Also, the experimental version of PHPLIB has a new directory > structure that is quite good in my opinion. Unfortunately, this version is > currently broken. I was thinking of using the experimental but I'd like some guidance here from the PHPLib developers. Folks, what you say? :) [...text deleted...] > > 4) Start moving things around. :) IE for example, probably move the Auth > > stuff from PHPLib into an Pear::Auth class. > > Sounds good. Some of this stuff makes use of the DB class so it may be a > bit tricky to let it stand on its own. > Well, that means that we'll have to replace the DB_Sql stuff with Pear::DB code... that's just part of the "pearizing" of the code... > > 5) Repearize the moved classes as needed. > > Not sure if this step goes here. My thought is if/as we moved code around, if changes were made, we might have to reapply some pear coding styles... > > > 6) Write wrappers around the newly moved classes to behave as the old > PHPLib > > classes. > > I am becoming a bit more pessimistic that PHPLib will survive unchanged by > a merge. I hope we can maintain backward compatibility but if some of the > principal developers behind PHPLib do not get involved, then I don't know > if we should feel too compelled to maintain backward compatibility. What > PHPLib is providing at this point is an initial API for some fundamental > application development classes - Auth, DB, Perm, Sess, Form, Table, Menu, > etc... The underlying implementation may change quite a bit - PEAR:DB may > be used instead if speed issues can be resolved. The API will likely have > some superficial changes (studlyCaps for method names) as well as some not > so superficial changes. There will certainly be some inertia to change the > API simply because there is alot of well tested and well thought out code > to work from. We may encouter alot of impedence mismatch that may require > changes however. > > my 2 cents > > Regards, > Paul Meagher My thought is there are probably a lot of people out there who are using PHPLib in their projects now and don't want/need to rewrite it. Therefore, if we have a wrapper that provides the original functionality, then that is a GOOD thing... :) We get them using pear almost with out them knowing it... -- Jeff Stuart jstuart@neo.rr.com