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

Paul, not a problem... :)

> -----Original Message-----
> From: Paul Meagher [mailto:[email protected]]
> Sent: Thursday, March 08, 2001 9:01 AM
> To: [email protected]; 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
[email protected]