Subject Re: Installing Perl DBD on a client machine
Author Bill Karwin
--- In ib-support@y..., "David K. Trudgett" <dkt@r...> wrote:
> On the other hand, IBPerl has always been the best Perl interface to
> InterBase. Bill Karwin did a great job with it, and it's very easy
to
> use. The DBI interface is very generic and "lowest common
> denominatorish", and it is my understanding that IBPerl makes
> available several useful InterBase features that are not available
to DBI
> programmers.

Hi! Helen asked me to contribute to this thread.

I first developed IBPerl in 1996, when Tim Bunce's DBI specification
was poorly documented and changing constantly. It was too unstable
for me, so I wrote something independently. I also had the
opportunity to surface some IB-specific features (like decoupling
transactions from connections, which most database interfaces like
ODBC/JDBC/BDE assume are inseparable).

DBD::InterBase actually made use of IBPerl for some time, instead of
reinventing a binding to the InterBase API. Thus DBD::InterBase
bundled IBPerl in its distribution and passed requests through to the
IBPerl classes.

More recently, I think Ed Pratomo, who is responsible for
DBD::InterBase, rewrote it, so it doesn't use IBPerl.
Understandable, since I wasn't updating IBPerl much, and one could
easily conclude that it was an orphaned project. There's now a
DBD::InterBase project on SourceForge
(http://sourceforge.net/projects/dbi-interbase/).

I agree that today, DBI/DBD forms the de facto database interface for
the Perl community. There's even an O'Reilly & Associates book on
it. I recommend using DBI/DBD to keep a reasonable level of
conformance and portability. While the IB-specific features are fun
and can result in some efficiencies, they're rarely needed. If you
*are* truly in need of such complexity, should you be using a
scripting language at all?

There actually is a way to extend the DBI interface in vendor-
specific ways, though I haven't fully figured it out yet. So one
could in theory use DBD::InterBase, but also add a few optional
methods to permit access to the good stuff. The best of both worlds!

I'm not sure there's a place for IBPerl anymore. But that's okay, it
served its purpose for its time. There are other projects I'd like
to do now! :)

As for Perl 6, I would guess that for a while after Perl 6 is
released, the majority of Perl users won't be using it. A lot of
Perl programmers in the real world are *still* maintaining Perl 4
scripts, without any object-oriented features!

Regards,
Bill Karwin
billk@...
(temporary, until my karwin.com domain gets transferred)