David Nicol wrote:
On Mon, Sep 12, 2011 at 5:20 PM, Darren Duncan <dar...@darrenduncan.net> wrote:
How mandatory, currently, is the "mandatory shared codebase?" Are
there really traps and snares preventing
a different framework from using DBD modules? I'm presuming that there
aren't; ICBW.
So getting away from the "framework" mentality is the point here.
I've got the idea (and also the feeling that carrying on this
discussion on-list is dubious; but I think I might speak for others)
I see the dbi-dev list to be equally about discussing implementation/design
matters that are common to DBD development, because they share a user API by
design, and not just about the "DBI" distribution itself.
So in that respect, I consider this very on topic, at least if my proposal is
accepted as the official evolution of the DBI itself, from code to a spec, where
the latter, for the forseeable future, matches the former exactly as possible.
Ultimately then, this list would be about what it is currently about to a large
extent, which is DBD development, and managing the API they agree to share.
that your proposal is a change in one's way of looking at the
architecture, rather than a proposal for a change to the DBI. A lot of
other framework/module projects exist: firefox and qpsmtpd are but the
first examples that come to mind. Sometimes another framework can
replace the core, and plugins can be reused -- I think but am not
certain that chrome can handle some firefox plugins without
modification. I've often wanted to formalize the qpsmtpd plugin
interface to the point where a different MTA could use qpsmtpd plugins
unchaged, but haven't found the time for that. Actually the big SMTP
plugin framework is "milter" which is defined as a clean interface to
the point where other MTAs offer Milter interfaces.
Are you asking for something beyond documenting the DBI/DBD interface
to the point where a DBD can be used more directly than through the
DBI? Aside from requesting that everyone abandon the framework
mentality?
Are you asking for a stronger set of conventions in DBDs that will
make them more useful away from DBI? Are you proposing to write
thinner glue?
Fundamentally I propose an inversion of control, where users invoke DBD modules
directly that optionally invoke or compose DBI to help them, rather than users
invoking DBI that uses DBD modules to help it. The other stuff flows from that.
This is an outline of what I propose:
1. There be a paradigm shift of sorts for the DBDs themselves, where they are
conceived as something that are meant to be used directly by users, rather than
having their use mediated by a separate module which is DBI.
By normal Perl conventions this means say that users should write something like
this:
use DBD::Pg;
my $dbh = DBD::Pg->connect('...', ...);
... rather than:
use DBI;
my $dbh = DBI->connect('dbi:pg:...',...);
... and otherwise use it the same.
The choice of DBD can still be data-defined, for example involving:
my $dbh = $dbd_name->connect('...', ...);
2. Although DBDs are intended to be used directly, they have a promise to
implement a common user API, which is formally documented. Each DBD has its own
documentation, but also refers to the spec, and the spec includes user
documentation which each DBD effectively composes by reference.
3. The separate "DBI" module as it is known now would no longer exist as far as
regular users are concerned. For those DBDs wanting to share that code, the DBI
code just becomes an implementation detail of said DBD modules rather than
something users have to think about.
4. As DBI is an implementation detail of DBDs, it can be refactored into
something that doesn't know about individual DBDs, eg the hard-coded driver
function prefix registry can be eliminated, and it would just provide default
implementations of the routines defined in the documented API spec, to be
composed by the DBDs, or utilities, so not a huge amount changes.
5. A separate lightweight "DBI" module could still exist, say that just
provides "DBI->connect()" so existing DBI users can upgrade with zero changes
rather than a single change without having anything break, but all it does is
turn around and invoke the DBD using the defined API that users should normally
use for new/updated projects. This shim would be considered deprecated.
5b. On the other hand, I would wonder how much code there is out there that
does things like testing whether an object it is given is of a specific,
"DBI::*"-named class, and so might break if it got a "DBD::Pg::*"-named class
instead. Probably not most code, but if there was any, then it might break.
Not that modern code should be doing this. Something to look into.
-- Darren Duncan
