Re: Re: one abstraction layer (my proposal for)

> The time that passes is not in favour of PHP. Despite what I wanted to > believe, a lot of people is being moved to commercial platforms that > have been catching up like the .NET platform using Microsoft products > like ASP.NET. This will be more evident later but you can already see > people with that mentality. One of the arguments is that PHP lacks of > database portability and only works ok with MySQL. We know this is not > accurate, but you know that most people is not so technically aware and > can swallow arguments like this. > > A lot of consultants and sales people that want to defend concurrent > products are using the argument of lack database independent API to > defeat PHP. I am sure that some of you are aware of this. For those that > are not aware, here is a precious pearl of difamation against PHP so you > can see how much PHP has to loose because of this bad fame. Follow the > links to see even more difamation even against Zend and other unrelated > issues. > > > http://babelfish.altavista.com/translate.dyn?lp=pt_en&doit=done&url=http://www.plugsys.com/brasil/products/msp20/tours/qa/qa04.msp > > Anyway, things like this are part of the reason why I proposed wrapping > PEAR-DB around Metabase API. It would certainly be a solution that would > be feasable and reliable in much less time than your proposal takes to > accomplish. More on this below. Now for other comments... > Manuel, this PR problem will exist whether or not PEAR includes Metabase or not. As I understand it Metabase currently is a fully functional database independent API + much more which no other language has and has been around for x years (where x > 2 right?). Even if Metabase were magically ported to C tomorrow and the native APIs done away with so that the only way to access a DB was through Metabase, this nonsense would still be spouted - and is easily refuted. There is bad PR like this about linux, apache, mysql, postgres, etc, etc yet AFIK no of these projects based a technical decision on PR (leave that to the proprietary software vendors). Paul