Manuel Lemos wrote:
> 
> Hello,
> 
> "Stig S. Bakken" wrote:
> >
> > Jean-Michel POURE wrote:
> > > Optimization can only be achieved at application level, i.e.
> > > - in your database structure,
> > > - in the core PHP code of your application.
> > >
> > > Using MySQL, you will never ever achieve good results. Try PostgreSQL with
> > > embedded PL/pgSQL language and triggers, this will multiply the speed by
> > > 10, at least.
> >
> > Well, not everyone is using SQL databases, for some people (including
> > me), CPU is the real bottleneck.
> >
> > Rewriting the "PEAR" class to C would IMHO not be foolish: it would save
> > basically everyone using PEAR from parsing ~800 lines of code for each
> > request, and it would speed up error handling and every other basic pear
> > function.  To me, that's a well-invested optimization (since everyone
> > benefits from it).
> 
> There is no great point on using database abstractions unless you want
> to develop database independent applications by using the same API. The
> way I see it PEAR-DB does not provide enough database independence. For
> many things you still have to resort to database specific solutions, so
> your applications will still not be portable. If they are still not
> portable using PEAR, you may as well not use PEAR or any other database
> abstraction package and save yourself of the overhead of using any of
> such packages. So, database abstraction package should provide true
> portabilty to applications. If you are going to port PEAR to C you
> should rethink PEAR design to make it provide portabilty.
> 
> Proposal: how about porting Metabase API instead? Think about this:
> 
> - Metabase API already provides true portability to database
> applications, so you would not need to crack your head doing what
> Metabase already does.
> 
> - You could wrap PEAR DB classes around Metabase API so the current PEAR
> DB users would not need to rewrite they applications.
> 
> - You could have a portable database API in PEAR right now using the
> current Metabase PHP implementantion, and not in a year or whatever is
> the time you would take to port PEAR DB to C.
> 
> - You could already benefit from Metabase database schema management
> support features that no other database API offers, not in PHP nor any
> other language.
> 
> - You could use Metabase driver conformance test script to verify if you
> porting efforts of the drivers are being correctly implemented.
> 
> - Benefit from the already extensive documentation and tutorials that is
> provided with Metabase.
> 
> - Benefit from the toons of Metabase based programming components and
> applications that have been developed.
> 
> - 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.
> 
> Well, this is what I meant to talk to you in San Diego O'Reilly Open
> Source Conference and in Frankfurt, but for whatever reasons you could
> not attend. Anyway, I am giving the hand for cooperation. It is up to
> you to decide if you would like to take this chance for the benefit of
> the whole PHP community.

I'd very much like to see the features of Metabase in PEAR DB.  If you
want to do this, I'm all for it.  Let's be done with the bickering, work
together and have _one_ abstraction layer for PHP.

I suggest making a prototype called "MDB" providing PEAR DB-compatible
wrappers around the Metabase API first.  If this is successful, I think
a C rewrite is due, the result being PEAR DB 2.0.  IMHO the natural way
of doing the C rewrite is copying the existing database extensions and
rewrite them with a common PHP-level API.

 - Stig

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Reply via email to