Front page | perl.dbi.dev |
Postings from September 2011
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 DuncanThread Next