David Nicol wrote:
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?
Okay, actually, for the short term I propose something considerably less
controversial, which can set the stage and ease transition for my other
proposal, but without committing us to it.
I propose making a few additions to the DBI as it is now, such as a few routines
to the various user-facing DBI packages, which are then documented as the new
way to introspect certain things such as that the object or package someone is
looking at does indeed implement the DBI protocol, and its version, etc, and
document that stuff like users testing $dbh for their package name is deprecated
and is not expected to continue working in the future.
Also make additions to any or all DBD as required so that one can use them
directly if they want to, but they also continue to work the old way. Said DBD
would also document that direct use is the recommended way to use them, and that
using them by way of "DBI" is deprecated.
And have documentation describing/defining the DBI's API.
Then wait a year or two, and then make further updates that cause uses of the
deprecated APIs to warn.
Then wait a year or two, and optionally remove those, or wait longer considering
how mature these things are.
So basically I propose making the small additions so that users can experience
the inversion of control, but also use the DBI the old way too, and so give a
solid transition period.
Then, at any time, one can choose to create a new DBD that just works the
new/inverted way, and users can use that and legacy DBDs at the same time.
-- Darren Duncan
