As I continue to evolve the Muldis D language spec, I have come to decide that
the Muldis Rosetta implementation-to-be needs replacing.
Originally, Muldis Rosetta, whose skeleton I started publishing on CPAN at the
beginning of 2003, was intended to be database framework like the Perl DBI, with
shared command-design-pattern-interface-defining classes and DBMS-specific
implementing classes, which the DBI calls "drivers" and which I call "engines".
Muldis Rosetta's main difference from DBI was that its interface also defined
a shared query language (Muldis D) that users wrote in and was translated to the
native DBMS query languages, rather than users writing directly in the
DBMS-specific query languages; this aspect of greater portability is why it was
named "Rosetta".
But now, as the language Muldis D has taken center stage of this Muldis database
ecosystem, rather than merely being part of Rosetta's interface, and thinking
about various practical concerns, I believe a larger reorganization is in order.
I have decided to take a page out of the PSGI ( http://plackperl.org/ ) handbook
and do away with the shared interface classes entirely, so further divorcing
from how DBI works. Instead, I will have a specification document, or rather a
distinct one for each general purpose programming language (starting with one
for Perl 5 and one for Perl 6), which describes a common API for a database
implementing or accessing library. This way, we keep the old system's (or
DBI's) benefits of different implementations/drivers being drop-in
substitutable, but this is accomplished through duck-typing (term?), rather than
each implementation/driver needing a dependency on a common codebase like with DBI.
In Perl 5, each implementation of this spec would be its own collection of (or
single) Perl modules, and users only have to know and specify the name of the
initial module (like they have to know the name "DBD::Pg") and otherwise no
mention of anything specific to the one implementation has to be in the code.
For a loose DBI-alike example:
use FooDB;
my $dbms = FooDB->select(); # the DBMS is a singleton
my $sth = $dbms->prepare(<query code here>); # also "connect" with query
code
$sth->execute(<query params go here>);
...
Aside from the first 2 lines that say "FooDB", as long as the program keeps
$dbms around, it can get to everything by calling methods on it. Those methods,
as well as the methods of any result objects of those methods, are described in
the specification document, but most notably the names of the object classes are
not specified, and from a user perspective it shouldn't matter, eg whether the
objects are of FooDB::DBMS/FooDB::STH or any other Perl package names at all.
So implementations have great flexibility to structure how they like, and each
one can have as few or many dependencies as it wants. Several
implementations/drivers can also choose to get together and have common
API/other dependencies or shared code such as with DBI, but that isn't necessary.
Concerning the Muldis::Rosetta code that currently exists:
1. The Muldis::Rosetta::Interface* Moose roles will simply disappear, and this
is the mandatory shared codebase gone. The Muldis::Rosetta::Engine::Example
Moose classes, some of which compose the above roles, will no longer compose
them but should otherwise behave identically, barring other changes. The
Muldis::Rosetta::Validator modules will no longer check that objects compose the
Interface roles.
2. The ::Example and ::Validator module groups will be split apart into their
own distros and be appropriately renamed. The "Muldis::Rosetta" distro will
cease to exist.
3. The ::Validator module group will probably just cease to exist in anything
resembling its current form. Instead, it would be redundant in the face of a
general Muldis D test suite that I planned to have anyway, which consists of a
bunch of code files written in Muldis D that are just invoked in a test harness,
like the Perl 5 / etc test suite is today. The main Muldis D test suite would
be host-language-independent and be shared by all implementations, same as the
Perl 6 suite is for all Perl 6 implementations. I was already intending to have
that shared suite before, but what is new is what would happen with ::Validator
as something complementary, and this is still to be decided.
4. The ::Example group will be renamed and it should come more into its own as
a project.
I want to rename ::Example to get rid of the "Rosetta" part and otherwise give
it a name more befitting of a DBMS implementation library, while still being
very clear that this particular implementation is only intended to be a
*reference* implementation of Muldis D, and as such its codebase is about as
simple as possible while providing all the Muldis D features and behavior; it
would not have the complexity to scale for enterprise production use or anything.
My current thought is to generally call it "Muldis D Reference Engine", or
"MDRE" for short. There would likely be more than one of these, such as
complete Perl 5 and Perl 6 versions; the above name would be shared by all,
while each one has a name suffix like "for Perl 5", similarly to how Microsoft
names their office suite "MS Office for Windows" or "MS Office for Mac". The
Perl 5 package name would be "Muldis::D::RefEng" or some such.
Feedback on naming this is welcome. I insist that the name start in "Muldis" as
that is how I'm branding everything, but beyond that anything can go. But keep
in mind that I don't want to take up names for this that would be better
reserved for an industrial-quality implementation.
The API specification would be distributed similarly to how the Muldis D spec
itself is, as an all-POD CPAN distro. That will probably change in the longer
term, but for now it works well. The root POD file of this distro would
probably be "Muldis::D::Perl5" or some such.
Now the Muldis::D::Perl5 distro would have another immediate purpose, which is
to hold the spec of the Muldis D dialect HDMD_Perl5_STD. I intend for my very
next Muldis D spec release to split /lib/Muldis/D/HDMD_Perl5_STD.pod and
/lib/Muldis/D/HDMD_Perl6_STD.pod out of the core distro and into their own
appendix distros, which are ::Perl5/etc. After this separation, the core spec
will just define the "normal plain text code" PTMD_STD dialect and how Muldis D
code is represented in the system catalog database. I am doing this now so it
is easier to evolve that core pair without having to slow down and duplicate
every step of those changes in the PerlN dialects also so to keep them in sync.
And there were always intended to be more HDMD dialects, one per host
language, while the remaining 2 core would always be shared. It just makes
sense to pull out and have together all the Perl-specific spec stuff.
On a tangent, I expect that, unlike Muldis::Rosetta for Perl 5, I will drop the
Moose dependency and just implement MDRE with native blessed values. While
Moose provides nice sugar and introspection, the nature of MDRE being a virtual
machine for a significantly different language, is that I wouldn't be able to
take much advantage of what Moose offers, because I would be reimplementing most
introspection/etc anyway in Muldis-D-specific ways, and there's little benefit
to MDRE having the added pile of external dependencies considering how much use
it gets from it. Part of the reason I was using Moose was for the roles, which
are no longer in use as an API feature. Another benefit is that Perl 5 programs
that prefer to run leaner and otherwise not use Moose can then use MDRE more
easily. To be clear, I won't be replacing Moose with any other sugar module;
any external dependencies MDRE still has will just be for implementing tricky
bits, such as bignum math. (For a prettier version, see the Perl 6 one.)
Thank you in advance for any feedback. The MDRE naming issue particularly.
-- Darren Duncan
_______________________________________________
muldis-db-users mailing list
muldis-db-users@mm.darrenduncan.net
http://mm.darrenduncan.net/mailman/listinfo/muldis-db-users
