Re: DBI drivers by duck-typing

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