Re: ONE database abstraction layer

Hello, Alex Black wrote: > > > > - Benefit from the toons of Metabase based programming components and > > > > applications that have been developed. > > Yep, though I don't view an API change as a huge deal in this regard. I > think you could provide some basic 'metabase backward compatibility' scripts > that would allow old stuff to > keep working, but I wouldn't mind an OOized api in any 'native' C version. Before anybody misunderstands anything, for the record, I do not intend the current to drop Metabase API. There is people with large applications depending on it. Some of those applications are being sold or used for hiring paid services. This means that there is people making a living on products that depend on Metabase. It would be extremely unprofessional to leave these people out in the cold regardless I don't owe them nothing. The point here is to allow PEAR-DB to inherit Metabase features in much less time that it would take PEAR developers to develop them until it reaches a mature state. The intention for now is not to drop the current Metabase API but rather make a test wraping Metabase in PEAR-DB driver. This test needs to be accomplished real soon or else there isn't much point on this initiative. > > > > - 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. > > Yes. It's rediculous. Take the best ideas from each, use them. Get on with > it. > > PEAR DB has a nice API > Metabase is solid, tested, well documented and has fantastic unique features > ADODB (um, despite its owner.. mini flame) is fast. > > Those things are good. Change the name to PHP Database Layer or something so > noone can argue about ownership, give everyone credit, and enjoy having a > single abstraction interface :) There is no need to change names. PEAR-DB will still be PEAR-DB and Metabase will still exist without PEAR because there are thousands of users that rely on Metabase like that. Regards, Manuel Lemos