Re: Adoption of Metabase

Hello. "Stig S. Bakken" wrote: > > > > > already knows my views on the function naming, and I would really like to > > > > > see it have an API like PEAR-DB - not a wrapper (more overhead) but truly > > > > > rewritten, to the PEAR standards. > > > > > > > >Shifting Metabase API to something else would meant droping support to > > > >all the existing Metabase applications. The PEAR-DB wrapper was more to > > > >keep the PEAR-DB API to please people that are already using PEAR-DB. > > > > > > But we don't want to have an API that in 2 years time we will look back and > > > wish we had changed - by which time there will be many more people using > > > it, and so it cannot be changed. If we changed the API we could always > > > write a Metabase wrapper for it :-) > > > > I don't think there is much need to change PEAR-DB API, except for > > adding what is missing. > > I am open to incorporating features from Metabase that are missing from > PEAR DB. Metabase seems to have solid implementations for the databases > it supports (unlike DB, where many are left behind, such as sybase and > odbc). But I think an architecture redesign will be necessary to > provide enough modularity to provide the flexibility required without > too much request startup overhead. In particular I would like to use > more aggregated objects for a plug-in architecture that would allow > people to load the code for feature sets only when they are needed (like > you mentioned on the metabase list about separating the data definition Yes, that has been planned for a while. > queries into a separate "driver file"). Also, I'd like to explore the > possibilities provided by Andrei's new overloading extension. I am not aware of that extension. > I agree that it's time to start consolidating the most popular database > abstraction layers out there. I think the redesign I outline above > should be able to provide users with both runtime performance ala. ADODB > _and_ portability ala Metabase. You may make PEAR-DB interface with Metabase right away as it is because the changes that will happen to Metabase to make it more modular will be backwards compatible, so what interfaces with Metabase right now will work as it is now. Regards, Manuel Lemos