To be brief, ...
I don't know if this has come up in past discussions about the next major DBI
version, but I'll say it now, since its also what I'm doing with my own
DBI-alike ecosystem to be.
I believe that DBI should go away as an actual piece of code and instead be
replaced by an API specification document, taking PSGI as inspiration.
A DBD would be re-defined as a module that implements said documented API
specification, and that's it.
The DBDs would be mutually severed from there being a mandatory shared DBI
codebase which can aid in their maturity and optimizability.
The existing DBI code can be refactored into reusable utility modules or roles
that a DBD can *optionally* depend on in its implementation. This also means,
for example, that said DBI roles could more freely be Moose roles, while DBDs
that don't want that overhead aren't required to use it. Or the shared parts
could be identical to the current DBI, more or less, same dependencies. Or the
choice between XS vs pure Perl is more clean, and is a quality of just each
individual DBD.
The concept of gophering in DBI would change into a "middleware" concept.
The concept of driver-specific methods, like pg_*, just become ordinary DBD
methods that are beyond what is defined by the DBI spec.
So the new DBD is anything that quacks like a DBI, as defined by documentation.
And of course, the DBI document would be versioned, and part of the API it
defines is that one can programmatically query what version(s) of the DBI spec
the DBD provides.
So what say you?
-- Darren Duncan
