Re: [binarycloud-dev] Re: [PEAR-DEV] Re: [metabase-dev] RE: [PEAR-DEV] New Metabase Aniversary release

On Tue, 2002-01-22 at 21:07, Alex Black wrote: > > * 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 > developers. > > 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 > that happens. > > _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 :) It is definitely not my intention to have several database abstraction layers. The most-used classes are best kept unique, and database abstraction seems to be the most obvious one of these. But to respond to Manuel's request: *yes*, I do want to see Metabase and PEAR DB merge. But as Lukas says, we have to see that the merger works before we can commit to replacing the current stuff. - Stig