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.

> 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.

> 3) Initial Pearize of the phplib classes... (IE PHPDoc/style changes to
> functions/var names).

The hardest part may be trying to integrate this stuff with the PEAR error
class.  I don't have much experience with the error stuff but this is high
on my list of priorities and I hope to reopen some discussion on the theory
behind PEAR's approach to error trapping and reporting.  I want to look
over the PEAR error class I talk theory here.  If someone wants to talk
about it before then, feel free :-)

> 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.

> 5) Repearize the moved classes as needed.

Not sure if this step goes here.

> 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