Tim, thank you for your response.
I had posted my RFC more than 2 weeks ago and was starting to be concerned that
no one had yet made the slightest comment on it.
Your response of today has addressed my primary questions and concerns, for
which I greatly appreciate that, and it will help me to move onward.
The first main outcome is that I will not operate under any pretense of trying
to name my work "DBI" and will seek some good alternate name.
So far this is the working title NAME I have been using, for the API spec
written in the form of a POD-only distribution, with separate Perl 6 and Perl 5
versions:
Muldis::DBI::Duck_Coupling - Formal spec of a duck-coupling database interface
for Perl 6
To partly explain, "Muldis" is a brand base name I use for my projects, while
"DBI Duck Coupling" is descriptive for the project in common CPAN fashion.
If anyone wants to propose a better working title for the spec, I would
appreciate it. (My initial thought, just now, is that I could shorten the above
to Muldis::Duck_Coupling, but that fails in the sense that a verb should be
modifying a noun; otherwise I need a noun.) I know it just counts as bike
shedding, but it would be nice to have something that rolls off the tongue easily.
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.
-- Darren Duncan
On 2016-12-08 3:05 PM, Tim Bunce wrote:
On Wed, Nov 23, 2016 at 05:06:39PM -0800, Darren Duncan wrote:
This message is an RFC regarding Perl 6 and my proposed official successor
there for the current Perl 5 "DBI" module, and in particular for usage of
the "DBI" namespace.
I believe that now is the time for a serious look at having an official
"DBI" for Perl 6.
It's always been that time :) I disagree about "an" and "official" though.
I'd much prefer to see some real discussion (i.e. more than one person
actively involved) and some real code, rather than cannonize any vaporware
or any particular early experiments.
I think it's fair to say that the DBI has been reasonably successful.
That was due, in part, to the fact several people spent a good year or
so discussing and designing the spec, then spent another year or so
refining it as we worked on prototypes (DBI and DBD::Oracle).
I have already been working on a "Perl 6 DBI" or "Plack for databases" for
awhile now, and in a few weeks I should be ready to show it off for
evaluation. But in the meantime, I was hoping to get Tim Bunce and other
community stakeholders on board with its philosophy and get a blessing to
use the name "DBI" for it.
Nope. Sorry.
My position, FWIW, is the same as it was in this thread from Feb 2015:
http://markmail.org/message/oavyl5l4dlme5dft
which refers to this presentation:
http://www.slideshare.net/Tim.Bunce/perl6-dbdi-yapceu-201008
In this message I will outline a few main points to start off the
discussion, and other details can follow in the near future.
That is, the new "DBI" would actually just be an API
specification document for a duck-typing/etc API that conforming libraries
and applications would implement for themselves.
Which is also true for the "DBDI" proposed in the presentation.
It's an interface definition that follows closely the JDBC API.
(Which is mature, well documented, with a test suite, lots of books,
lots of people with experience, and maps well to underlying database
client library APIs. All *very* significant plusses.)
There's no need for any implementation of a DBDI interface to share code
with any other.
Does this sound like a proposal you can get behind,
You don't need me to get behind it. Write some code, get people to help,
build a team then a community.
Anyone else can do the same.
Give it any name you like for now. You can always rename it if it gains
traction. (The DBI was called DBperl for the first couple of years.)
is it okay to use "DBI" for the name reserved for the specification
There's no need for that. I think I'd prefer if nothing used "DBI".
(Except, one day, something that provided a very-DBI-like API over
whatever has been adopted by the wider community as a database API.)
Using it now, on an unproven experiment, seems like a poor idea.
do you have any questions or counter-proposals, and so on?
Write some code, get people to help, build a team. Give it any name you
like. Write a test suite. Release early, release often. Make it correct
and make it fast. Have fun. Good luck! :)
Tim.
