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 wil
David Nicol wrote:
On Mon, Sep 12, 2011 at 5:20 PM, Darren Duncan wrote:
How mandatory, currently, is the "mandatory shared codebase?" Are
there really traps and snares preventing
a different framework from using DBD modules? I'm presuming that there
aren't; ICBW.
So getting away from the "f
On Mon, Sep 12, 2011 at 5:20 PM, Darren Duncan wrote:
>> How mandatory, currently, is the "mandatory shared codebase?" Are
>> there really traps and snares preventing
>> a different framework from using DBD modules? I'm presuming that there
>> aren't; ICBW.
> So getting away from the "framework"
David Nicol wrote:
On Mon, Sep 12, 2011 at 3:13 PM, Darren Duncan wrote:
So what say you?
I think you can do this without any change to DBI.
You have your own DBI-like framework; you could declare that anything
that passes your conformance suite
is compliant, and offer low-impact patches to
On Mon, Sep 12, 2011 at 3:13 PM, Darren Duncan wrote:
>
> So what say you?
>
> -- Darren Duncan
I think you can do this without any change to DBI.
You have your own DBI-like framework; you could declare that anything
that passes your conformance suite
is compliant, and offer low-impact patches
I was sent a response to this off-list, part of which I'll reply to on-list.
The response bit was:
"What happens to the 'which drivers are available' part of the DBI interface?"
To this I say:
The API definition would say that each DBD has something which can be easily
scanned for, and so an
Replying to myself, ...
I believe that this fundamental design change can be accomplished with almost
full or entirely backwards-compatibility to existing DBI-using codebases.
This partly by a "DBI" package still being available which essentially provides
shims for people saying "DBI->connect
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 spe
On Sun, Sep 11, 2011 at 11:25:20PM +0100, Andrew Ford wrote:
> I suggest that we move this discussion to dbi-dev.
[dbi-users dropped]
> On 11/09/11 18:14, Tim Bunce wrote:
> >On Fri, Sep 09, 2011 at 03:50:53PM +0100, Andrew Ford wrote:
>
> my $next_middleware = $go_transport->middleware;
>
