A discussion started on dbi-users which I thought seemed more appropriate to
continue on dbi-dev assuming it caries on in the direction of a design
discussion. I have quoted the important parts of each original message below,
to get it started. -- Darren Duncan
-------- Forwarded Message --------
Subject: Perl 6 and DBI
Date: Thu, 5 Feb 2015 00:23:40 -0000
From: Greg Sabino Mullane <g...@turnstep.com>
To: dbi-us...@perl.org
As you may have heard, Larry Wall gave a speech recently declaring
the goal of releasing Perl 6 this year, 2015. Honestly, there
is little chance of me using Perl 6 until it has a good, working
DBI. Anyone know the state of things with DBI and Perl6? Is the
goal still to implement what is basically DBI v2, or perhaps
someone is working on a simple port of the existing DBI? Is
a working DBI even on their list of blocker features for a release?
-------- Forwarded Message --------
Subject: Re: Perl 6 and DBI
Date: Wed, 4 Feb 2015 16:28:15 -0800
From: David E. Wheeler <da...@justatheory.com>
To: Greg Sabino Mullane <g...@turnstep.com>
CC: dbi-us...@perl.org
This goes for me, too, and many, many other people too, I’ve little doubt.
-------- Forwarded Message --------
Subject: Re: Perl 6 and DBI
Date: Wed, 04 Feb 2015 17:19:54 -0800
From: Darren Duncan <dar...@darrenduncan.net>
To: David E. Wheeler <da...@justatheory.com>, Greg Sabino Mullane
<g...@turnstep.com>
CC: dbi-us...@perl.org
And in that case, there would/should be a discussion about what form this DBI
for Perl 6 should take.
Personally I think one of the most important design changes DBI should make is
that DBI becomes an API spec that drivers/engines must conform to in order to be
certifiably compatible. Part of the API is that user code can query the
driver/engine to ask, "do you implement DBI" or "do you implement this version
of the DBI API" etc.
DBI should not be an actual code layer that applications have to go through in
order to talk with the driver/engine, as it is now.
However, there can exist Perl 6 roles or other shared libraries that a
driver/engine may optionally use to help it implement the API rather than
rolling its own.
Think of the kind of revolution that PSGI brought by working this way, just
defining an API or protocol to conform to, rather than "being" a module that
everything had to use. DBI should do the same thing.
The actual details of the API / common interface are an orthogonal matter. The
key thing I'm looking for is no mandatory shared code between engines/drivers.
I also believe that what I said, the no mandatory shared code, would also work
just as well in any language, including a major new Perl 5 version.
-------- Forwarded Message --------
Subject: Re: Perl 6 and DBI
Date: Wed, 4 Feb 2015 21:52:39 -0600
From: David Nicol <davidni...@gmail.com>
To: Darren Duncan <dar...@darrenduncan.net>
CC: David E. Wheeler <da...@justatheory.com>, Greg Sabino Mullane
<g...@turnstep.com>, dbi-us...@perl.org <dbi-us...@perl.org>
Does this mean the floor is open for brainstorming? I'd like to see more
transparent integration, so p6+dbi would be like pl/sql or pro*C or whatever
that language Peoplesoft scripts used to be in that I was working with when I
wrote DBIx::bind_param_inline.
http://perlbuzz.com/2008/12/database-access-in-perl-6-is-coming-along-nicely.html
http://www.mail-archive.com/dbdi-dev@perl.org/maillist.html
doesn't have anything new since 2011.
