First steps... Goals, Assumptions and Principles

Hi.

I've a rough document I've been using to capture my thinking as I've
been going along. I figure the best way to start is to post one section
at a time for feedback.

So, without further ado, here's the first section - and it's probably
the most important at this early stage.

Any and all thoughts, criticisms, comments, questions etc. are most welcome.

Tim.

=head1 Goals, Assumptions and Principles

=head2 Original DBI Goals 

These goals were first defined around May 1994
in http://cpan.org/modules/dbperl/DBI/dbispec.v05

  1. Provide an interface with sufficient capability to be useful.

  2. Be simple to use for simple applications.

  3. Have sufficient flexibility to accommodate unusual or proprietary
    functionality (events etc) and even non-sql databases.

  4. Conform to or anticipate applicable standards where practical.
     Especially the X/Open & SQL Access Group SQL and CLI standards.

  5. Enable the creation of database-independent perl scripts
     but not limit you to the lowest common functionality.

  6. Support dynamic loading of database drivers.

  7. Support concurrent access to multiple database engines.

  8. Be freely available.

I think it's fair to say that the DBI met all those goals, and more.

=head2 Additional Goals for New DBI

  9. Define the DBI and drivers in terms of multiple interfaces to simplify
     reuse or replacement of components.

 10. No compiling for installation - DBI in Pure Perl and/or Parrot, drivers
     should use NCI to interface with to underlying database client APIs.

 11. Share drivers across all languages targeting Parrot

 12. Greatly simplify the development of new drivers

 13. Include some measure of type safety (compile time checking) as far as is
     cheaply practical.

=head2 Assumptions

=item 1

The Perl 5 DBI will be available from Perl 6. Either via Ponie or by embedding
libperl5 in some way.

This implies that the new DBI is less urgent than it otherwise would be.

=item 2

The Perl6 DBI API need not be very similar to the Perl5 DBI.

Given assumption 1 above, those who want to keep using DBI v1 can do so.

[For now I'm leaving open the question of whether the new DBI should be named
"DBI2" or keep the name "DBI" and bump the version to 2. There's a whole bunch
of issues there that are best left till Perl6 is more complete and CPAN
infrastructure like PAUSE have some Perl6 support. So I'll leave it for now and
use both "DBI2" and "DBI v2" interchangeably.]

=item 3

The DBI as we know it will be split into two layers. The Perl6 DBI will be a
relatively thin interface layered over a Parrot-level API.  It is hoped that
the Parrot-level API will serve as a common database interface for all
languages targeting Parrot. This is to support Goal 11.

The Parrot-level API is likely to be modelled on JDBC, the Java database API,
but with appropriate changes to suit Parrot rather than Java.  The Parrot-level
API is a mere implementation detail at this early stage in the process.

This document just outlines the Perl6 DBI API.

=head2 Principles

The DBI is primarily an Call Level Interface (SQL/CLI ISO/IEC 9075-3:1995)
and will remain so. (See http://en.wikipedia.org/wiki/Call_Level_Interface)

Any "Data Access Objects" functionality (like Microsoft ADO or Java JDO) should
be layered over DBI rather than being included within it.
By definition a DAO layer should be technology agnostic to enable change.
The role of the DBI is to provide a stable portable foundation to build on.

If it can be done outside the DBI it probably should. Either 'above' by
subclassing or wrapping the DBI, or 'below' by subclassing or wrapping drivers.

Learn from the good and bad parts of mature OO database APIs, such as JDBC.

=cut