Re: Re[2]: [PHP-PEAR] PHPLib and Pear merge

> Well, DB has affectedRows(), it is currently supported in mysql, oci8
> and pgsql.  The others return a "not capable" error.
>
> > PEAR::DB eats much more resources then DB_Sql and can't afford those
> > simple things which could be done in half an hour or less?
>
> Please, if you want to complain, at least make sure you complain about
> the latest version.

Stig, in case you are not aware, Maxim has made fundamental contributions
to PHPLIB in the form of classes for native sessions and serialization.  He
has a deep understanding of PHPLIB and, given that he has taken 2 months to
study PEAR, he probably understands it as well.  Personally, I would not
frame his comments as "complaints" but would seek further insight as to
where he is coming from.

To flip the tables, Stig, have you studied PHPLIB well enough to understand
what the strenghts and weaknesses of DB_Sql are?  Can you compare and
contrast your approach with that of DB_Sql?  Probably you can.  Just
wondering.

As an aside, I think it is good that we have two competing abstraction
layers for PHP.  The PEAR group may have become a bit too complacent about
their achievements if it were not for the fact that we have a DB
abstraction layer that is demonstrably faster than PEAR:DB.  I think that
it is a good thing that we have two fundamentally different approaches to
DB abstraction as I think at the end of the day it drives us to search for
a deeper understanding of fundamental issues and tradeoffs involved in
different OO approaches to web development.

This brings me to the project of "merging" phplib and pear.   My thoughts
are that our intial efforts SHOULD NOT involve the elimination of PHPLIB's
current DB Abstraction layer.  I think it is healthy to have more than one
approach to DB Abstraction.  I doubt that PEAR should even attempt to
provide one single best solution to DB Abstraction as we are only really
touching the surface of what is possible here.

Consider:

1. http://www.perl.com/pub/2001/02/dbix.html
2. http://www.oreillynet.com/~rael/lang/php/PRAX/
3. http://stein.cshl.org/AcePerl/
4. http://php.weblogs.com/ADODB
5. http://freshmeat.net/projects/metabase/

In other words, under the DB category, we should expect to see some
diversity in approaches.  I'm not sure how this jives with the constuct of
a single "package" underneath every major category.  As an aside, I
currently doing some work on developing code generators and am starting to
question whether you even need an abstraction layer if you can generate
native db code (for whatever db) on demand  for your app- a code generation
approach leads to more optimized code while also giving you db abstraction.
There are many ways to achieve db abstraction.

I have also been thinking about a possible roadmap for the phplib-pear
merge.

I wonder if some of these items should be on the immediate agenda?

1.  Release a PHPLIB4 distro with support for native sessions bundled with
some of the newer code contibutions.  If Maxim, Ulf, Bertrand, Sebastian
and Kristian and other PHPLIB core developers joined out sourceforge
effort, I think we would be able to achieve this fairly quickly.  The goal
would not be to release a fully polished version, but one that would
provide the pear-phplib merge folks with a base from which to work.  It
would also give the PHPLIB installed base a heads up that new things are
starting to happen.   I think the major piece of work involved in such a
release is making the experimental DB stuff work again?  Am I wrong?
Alternatively, could we just take PHPLIB 7.2, include the newer session and
user classes, and call that PHPLIB4?  I have been able to get that
combination working although I haven't done major testing of it..

2.  Incorporate PEAR_ERROR into PHPLIB.  My sense is that this is one area
where the PEAR approach can inform the PHPLIB approach.  It makes sense to
"merge" here.

3.  Incorporate the current work on Caching into PHPLIB.   If PHPLIB is
vying to be the fundamental application development framework for PHP, then
it would be good to add support for Caching as code for dynamically
generating menus, tables, forms, etc... would likely eat too many cycles on
a busy site without Caching support.  I think it would complement the other
fundamental PHPLIB classes nicely.

4. Should this be a Phplib-Horde-Pear merge?  Seems to me that Horde has
alot of good code as well that might be contributed to the app dev
framework.  Seems that HORDE has alot of parallel classes with some unique
features that might be used to expand the P(hplib)-H(orde)-P(ear) API for
web applications?

I think that Sourceforge is a good location for this work as it is neutral
ground for this effort.  I think it is important that we not feel the need
to integrate into PEAR immediately as PHPLIB is a larger repository of
source code for application development.  PEAR is not specifically focused
on appliation development and some question whether it should be.  If not,
then it doesn't make sense to religiously adhere to the PEAR coding
standards in our intial releases.  Creating a new distro (PHPLIB4) and
attempting to assimilate PEAR's error and Caching concepts makes more sense
to me.

Regards,
Paul