Hello, "Stig S. Bakken" wrote: > > > Rewriting the "PEAR" class to C would IMHO not be foolish: it would save > > > basically everyone using PEAR from parsing ~800 lines of code for each > > > request, and it would speed up error handling and every other basic pear > > > function. To me, that's a well-invested optimization (since everyone > > > benefits from it). > > > > There is no great point on using database abstractions unless you want > > to develop database independent applications by using the same API. The > > way I see it PEAR-DB does not provide enough database independence. For > > many things you still have to resort to database specific solutions, so > > your applications will still not be portable. If they are still not > > portable using PEAR, you may as well not use PEAR or any other database > > abstraction package and save yourself of the overhead of using any of > > such packages. So, database abstraction package should provide true > > portabilty to applications. If you are going to port PEAR to C you > > should rethink PEAR design to make it provide portabilty. > > > > Proposal: how about porting Metabase API instead? Think about this: > > > > - Metabase API already provides true portability to database > > applications, so you would not need to crack your head doing what > > Metabase already does. > > > > - You could wrap PEAR DB classes around Metabase API so the current PEAR > > DB users would not need to rewrite they applications. > > > > - You could have a portable database API in PEAR right now using the > > current Metabase PHP implementantion, and not in a year or whatever is > > the time you would take to port PEAR DB to C. > > > > - You could already benefit from Metabase database schema management > > support features that no other database API offers, not in PHP nor any > > other language. > > > > - You could use Metabase driver conformance test script to verify if you > > porting efforts of the drivers are being correctly implemented. > > > > - Benefit from the already extensive documentation and tutorials that is > > provided with Metabase. > > > > - Benefit from the toons of Metabase based programming components and > > applications that have been developed. > > > > - Stop this silly implicit competition between database abstraction PHP > > packages. There is much more to gain from cooperating than competing. > > None of us if making money from it. All popular languages only have a > > single database abstraction package (Perl-DBI, Java-JDBC, ODBC/ADO for > > Windows languages, Python-DB, etc..). There is still a wrong idea in the > > PHP community that there is no abstraction package in PHP. > > > > Well, this is what I meant to talk to you in San Diego O'Reilly Open > > Source Conference and in Frankfurt, but for whatever reasons you could > > not attend. Anyway, I am giving the hand for cooperation. It is up to > > you to decide if you would like to take this chance for the benefit of > > the whole PHP community. > > I'd very much like to see the features of Metabase in PEAR DB. If you > want to do this, I'm all for it. Let's be done with the bickering, work > together and have _one_ abstraction layer for PHP. > > 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? Regards, Manuel Lemos -- PHP Development 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]
