Re: Re: ONE database abstraction layer

On Tuesday 27 November 2001 07:36 pm, Manuel Lemos wrote: > > > > I suggest making a prototype called "MDB" providing PEAR DB-compatible > > wrappers around the Metabase API first. If this is successful, I think > > a C rewrite is due, the result being PEAR DB 2.0. IMHO the natural way > > of doing the C rewrite is copying the existing database extensions and > > rewrite them with a common PHP-level API. > > Ok, I don't have much time right away because I am working full time on > the development of MetaL at least until the end of the year. > > That doesn't mean that other people could not start working on PEAR-DB > wrapper around Metabase. For instance, Lukas Smith was willing to have a > Metabase interface with a more OOP like syntax ($db->MetabaseFunction). > Maybe he would like to write wrapper class with PEAR-DB API and both > goals could be achieved. What do you think Lukas? > SiteManager (www.roadsend.com/siteManager) also has an interest in getting Metabase "ported" to PEAR. While we looked at using Metabase exclusively for the database extraction layer before 2.2 stable was released (on a tip from alex@bc :), in the end it was the API that didn't fit into the SiteManager framework, and so we went with PEAR. The more OOP like syntax that you mention above is exactly what I was looking for before. Now that SiteManager uses PEAR, however, I'm obligated to keep the same API so as not to break backward compatiblity with SiteManager based sites. Thus a PEAR wrapper around metabase would be beneficial - but what are the performance issues, I wonder? It seems instead of SiteManager->PEAR->db I would move to SiteManager->PEAR->Metabase->db. Performance is one of the key issues of our current development line. Of course a C port makes all of that moot.... And while it's clear that many could benefit from such a port, perhaps the hardest part would be finding enough people with the time to work on it.... Shannon