> * Manuel Lemos wrote:
>> I think that the greatest point of the merger is to have one and only
>> one abstraction layer in PEAR,
> I think consensus was that there shouldn't be "the one and
> only XYZ" PEAR class but "more than one XYZ" PEAR class (like
> IT[X] and the PEAR rewrite of PHPLib's Template class).
Again, I agree about everything but database abstraction.
It's fine to have applications use 5 different template engines as its only
a matter of taste. binarycloud supports smarty, xslt, and standard php
classes.. I'm sure we'll support more in the future.
The database abstraction layer's behavior and capabilities dictate
application development and we sure as hell don't want 5 abstraction layers
with the same API floating around. IMHO that's actually _worse_ than just
having different abstraction layers compete, because it can confuse new
We had this discussion a while ago, I was actually under the impression that
everyone agreed that metabase was the most architecturally and functionally
mature package, while PEAR clearly had a cleaner OO api because it wasn't
burdened with PHP3 compatibility.
I would _very_very_very_ much like to see metabase core code replace the
current PEAR::DB codebase, but use the same API as the existing PEAR::DB.
PEAR people and us out there building applications have a lot to gain if
_If_ that happens I think we are all better for it: we gain both the good
api and the mature package... and everyone can start using the same
abstraction layer so we can all start sharing applications properly (again
one of the primary ideas behind binarycloud).
If it is indeed the intention of those running pear to (in the long run)
have multiple abstraction layers, I think that is a bad mistake. However,
until whoever decides these things makes themselves clear I don't really
have an opinion :)
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]