Re: general questions

At 04:54 AM 12/1/01 -0200, Manuel Lemos wrote:

I think you miss the point of the whole vision, but I will try to explain it again. If all goes well, in the end you only have PEAR-DB. My proposal is to wrap Metabase around PEAR-DB API. PEAR-DB API will be enhanced to provide an interface for Metabase features that PEAR-DB does not offer yet. If all goes well, Metabase API functions can be ported to C taking whatever it takes to do it, but until that is done you can already benefit of Metabase features with a PEAR-DB API today.

May I try to put across how I see this vision. This is my personal take on the project, may or may not reflect other people's views. We should have a unified database abstraction API (the PEAR-DB API + extras), which is basically what I think Manuel was proposing in the first place by wrapping Metabase. This has the following advantages: - I can swop database abstraction layers easily. If I need something fast then I can use ADODB. If I need a portable application then I can use Metabase. And for normal things I'll use the current PEAR-DB. And _all_ this works from one API - no more recoding when I realise that the current DBA doesn't have a feature I want. This means that we don't have to argue over which features should go into the layer for the time being - if I don't like the current one I can move. And eventually (I hope) we'll get down to one layer :-) Manuel, another thing I'd like to see is the schema management of Metabase become a stand-alone program (XML2SQL?) which could go in PEAR(?), as I think this is one of the most useful features of Metabase, and regardless of which DBA I use I'd still like to use this :-) Regards, Peter. -- Devon Railway Centre - a great day out! http://www.devonrailwaycentre.co.uk