Re: RFC: Official DBI for Perl 6

[email protected] (Darren Duncan)
Newsgroups perl.dbi.dev
Message-ID <[email protected]>
On 2016-12-09 7:41 AM, Greg Sabino Mullane wrote:
> Thanks for starting this thread.
>
>> Muldis::DBI::Duck_Coupling
>>
>> If anyone wants to propose a better working title for the spec
>
> That's pretty wordy, and other than "DBI" doesn't tell us what it is.
> How about DBAPI? Or something short and sweet.

For various reasons I have decided on a working title of the form Muldis::Foo 
where Foo is some short acronym of something descriptive.

I haven't yet chosen one but am about to.

Later on the proprietary Muldis:: prefix can be removed at about the same time 
as the project is adopted by a community management at least to the degree that 
DBI itself is, if that happens, and in the meantime I don't pollute generic 
namespaces with working titles.

>> The second main outcome is that Tim appears to endorse my primary design
>> proposal that all implementations of the API are permitted to be at arms length
>> and there are no mandatory shared dependencies, in contrast to "DBI" being a
>> mandatory shared dependency now in Perl 5.  No mandatory dependencies includes
>> no Perl 6 roles that must be consumed in order to declare provision of the API.
>
> Yeah, I have no major objections so far to the proposal. It would be nice to keep
> things close to DBI where it makes sense, but this seems like a good opportunity to,
> like Perl 6, keep the good stuff and replace the cruft.

So in my case, I'm reading between the lines and distilling what I see as the 
essence of the Perl 5 DBI without considering any legacy API details to be 
sacred cows, not only for my Perl 6 version but also for my Perl 5 version.

Likewise for JDBC, I am clearly intending to operate in a different space or at 
a different layer than Tim's long-stated preference for an API that directly 
mirrors JDBC.  For now we can consider it as a layer Tim predicted as going 
directly over his JDBC-based one in his DBDI model, though it could also go 
underneath the JDBC-based one, similar placement flexibility as the PSGI stuff.

> That's a tall order, of course, which makes me wish we had started this thread
> about 10 years ago. You know, that time when Perl 6 was just about to be released. :)

I believe we did, briefly.  I joined the DBDI mailing list in 2004, around when 
it started, I think.

The key difference now is that Perl 6 itself has actually been declared 
production ready by its creators, with a solid implementation and OS packaging 
infrastructure such that it is almost as easy for users to install and get into 
as Perl 5 or other common languages are, and presents a little-moving target to hit.

On a tangent, and for posterity, I'll share a response I got in private from 
Brock Wilcox yesterday, which I quite liked.

On 2016-12-08 7:06 PM, Brock Wilcox wrote:
> Random ideas:
> * DBDuck
> * DDuck
> * Duckie
> * ADI - Abstract Database Interface
> * QuackDB / QDB
> * DBP - DataBase Protocol
> * DBAL - DataBase Abstraction Layer
> * Dali - Database Abstraction Layer Interface
> * DAS - Database Abstraction Specification
> * DAR - Database Abstraction Role
> * DIR - Database Interface Role
> * DR - Database Role
> * Duncan's Database Role (DDR)
>
> In any case, great idea for doing this PSGI-style.

-- Darren Duncan
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.