DBI drivers by duck-typing

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