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

>> One database abstraction layer is all that is necessary. By all means have >> 15 different template engines, but do not have 15 different database >> abstraction layers: if we are to have interoperable code, we must have a >> single database abstraction package. > No program based on PEAR components is really interoperable at the moment. ;-| > You mentioned the right point comparing templates vs. db layer. your first point is a good one, but as far as I understand that _is_ a goal... and yeah, lots of template engines is one thing, lots of DB abstraction layers is another :) > We decided to support two types of template system in PEAR based on the > requirements - a lightweight (IT) and a heavyweight (maybe Smarty). At the A good choice in both cases. > moment PEAR::DB is just a unified API, not a unified SQL Layer. Metabase is > prepared more then PEAR::DB for SQL independent stuff. I see no problems > adding > a pearized Metabase to PEAR, due to to different APIs, sourcecode and > requirements. PEAR::DB and PEAR::Metabase could be equivalent to PEAR:IT and > PEAR::Smarty Ah, on this point I disagree, because of the interoperability issue: we want "heavy duty" applications (like binarycloud, for example) to be able to use "light weight" applications together in a larger project. If they all use and rely on the same DB api, the community stands to benefit a great deal because components can work together. This is not, for example, necessary with template engines. I don't care how a given application creates it output, it can use any method it pleases (though I like smarty :) - but I _must_ care about how it talks to my database. best, _alex