Re: PEAR and DB abstraction layer (was: PHPLIB)

Hello Jon, On 03-Jul-00 00:06:08, you wrote: >> >Wauw. PHP now has four DB abstraction layers that I have heard of: >> > - PEAR's (will probably work from PHP 4.0.1) >> > - PHPLIB's >> > - Metabase >> > - http://phpdb.linuxave.net/ >> >> >It would be great if at least some of the abstraction layer could >> >unite. >> >> Believe me that I tried, but the conclusion is that each one wants >> to go their way and have their package to prevail instead of >> cooperating to develop a single dominant database abstraction for >> PHP like there is for Perl, Java, Python, etc.. There have been >> intense discussions on this that ended in a impass, so there is no >> point to bring that up again. >I'm my opinion, the right thing to do is to pool all of our efforts >into PEAR. That way, we can treat it as a standard PHP component, and >we don't have to make assumptions about the end user (other than that >they have a recent version of PHP with PEAR). >Even if the other abstraction implementations are farther along or >just plain work better, they should be merged into PEAR so that all >PHP users can benefit from a common API out of the box. The problem is that PEAR-DB is very incomplete and it will take a long time to stablize with all the features that are need. PHP core developers decided to develop PEAR-DB from scratch instead of building on one of the existing solid PHP abstraction packages. PHP users need a database abstraction package now, not in one year or so when PEAR-DB is solid and has all the important features that others have now. From my experience, a good database abstraction package takes a long time to develop and stabilize on a definite API. I waited about a year until I decided that Metabase was ready for public distribution. It would have been a mistake to release sooner because the API evolved incompatibly during that period. It would cause harm to users keep release versions of the package that had incompatible API. I expect that happens with PEAR-DB or else it might get stuck in the evolution of its features to not break compatibility with earlier versions of the API. Therefore I don't recommend the adoption of PEAR-DB right now for larger applications or else you might end up having to rewrite large parts of of your applications later if PEAR-DB API compatibility has to be broken to let it evolve. I'm not saying this because I want you to use Metabase as alternative, but rather because I can see the risks of adopting a package that is bearly under development. Even not using any database abstraction package at all would be a better alternative for now. Personally I am not going to stop developing Metabase to spend time developing PEAR-DB so it can catch up sooner. I developed Metabase to satisfy the database abstraction needs of my projects. I need to move on and develop more components like those that I described in a previous message because I need them for my applications now. Since I live from the applications that I develop I can't justify stopping developing Metabase to walk backwards redoing what is already implemented in Metabase but adapted to PEAR-DB design. Maybe later if PEAR-DB catch up on the development at least up to the level that Metabase is in today, I'll consider merging, but I am not the betting on that. You know, free software development is based on good will be the developers. You can't just rely on the expectation that they will develop exactly the stuff you need. So, you'd better rely on what exists today and works for you than putting high hopes on something that you were never told that it will happen. Regards, Manuel Lemos Web Programming Components using PHP Classes. Look at: http://phpclasses.UpperDesign.com/?user=mlemos@acm.org -- E-mail: mlemos@acm.org URL: http://www.mlemos.e-na.net/ PGP key: http://www.mlemos.e-na.net/ManuelLemos.pgp --