Tomas V.V.Cox <[EMAIL PROTECTED]> wrote in message
> On Tuesday 20 November 2001 07:41, Manuel Lemos wrote:
> Hi Manuel,
> > I don't have the time or motivation to develop things for PEAR just
> > because it is funny to cooperate. I am no longer a college student so
> > I don't have plenty of free time to spare. What I do is because I
> > need the things for my job. If I am not selling what I do, I don't
> > have a problem with sharing. That is what I am doing with Metabase.
> That's the same here. At least me I'm here to develop stuff that I
> later use in my work, so indirectly you and me are making money with
> that as it helps our work to be more productive.
> > One thing is certain, I don't want to go where I am not wanted. If
> > there is no interest in integrating Metabase in PEAR, fine. If not, I
> > don't have a problem with that. From the silence of PEAR core
> > developers, I am afraid there isn't much hope from their side to
> > cooperate.  At least I made an honest attempt to cooperate.
> It will be very nice to have a unique abstraction layer where all of us
> contribute to. But in my opinion to impose MetaBase isn't they way to
> go. PHPLib, ADODB, PEAR DB all are good developments with their
> community and their developers, and trying to drop all of them with
> Metabase is a crazy idea.
> The only exit I see of the multi abstraction layers problems is trying
> to join all those communities and start a new development from the
> ground. The code is almost all written so only need to glue it to meet
> the specs of the new resultant layer. Then each team could provide
> their own wrappers to make things easy to their users. That's IMO a
> cooperative behaviour.
> Tomas V.V.Cox

Hi Tomas, Manuel, everyone,

I think that different programmers have different needs.
Metabase's goal is 100% DB portability. PEAR DB builds on the
PEAR classes to give a solid set of classes. ADODB is aimed
at converting the heathen ASP'ers to the "one true religion".
I also know of a PHP DBI class also from people who still need
the $perl~= /fix/;

Each designer has a different point of view, like Tomas has
written a really excellent oci8 "select limit" emulation, but looking
at the code, it's so complicated that i decided not to incorporate it
in ADODB because I value simplicity. I know Tomas' code works
in theory, and its really impressive that you even considered UNIONs,
Tomas, but I just like "simple" code that I can keep in my head.

I think some standardization in terms of API is good, but I don't
think most people care. Newcomers to programming will want to use
something easy and "standard" - is PEAR DB already the standard?
Windows programmers would want to use something familar. I already
have a prototype PEAR DB api wrapper for ADODB , and ADODB has
support for PEAR Error() also, but the people who like ADODB
generally are not that interested (at the moment).

> to join all those communities and start a new development from the
> ground. The code is almost all written so only need to glue it to meet
> the specs of the new resultant layer.

Actually the common code is already available: it is the
database extension API's. But most of the problems are
in the database extension APIs also, and our work is fixing
their mistakes.

-Oracle ocifetchinto() returns OCI_ASSOC arrays in uppercase,
 when everyone else is using lowercase.

-Magic Quotes murders our quoting, and what about magic quotes
 sybase which happens to be for interbase and sql server too!

-Postgresql does not have an error number to return. And there is
 no pg_insert_id() either.

-Interbase's API is missing an arm and a leg, and whether it is
 the left or right arm missing is not documented anywhere.

-All extensions should support blobs like Oracle, with a fetch mode
 that makes "SELECT blob FROM table" transparent with no special

If we fixed these problems and more, we could talk about having
a unified API. Otherwise for the Oracle OCI_ASSOC, I would prefer
not to change it for speed, Manuel would want to provide an emulation
layer, i would object because it's slow, etc...


PS: the history of windows shows it's ok to have multiple abstraction
layers: ODBC, RDO, DAO, ADO, ADO+, JDBC, Delphi's db classes, VB's data
controls, provided there is progress.

PHP Database Mailing List (
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