Muldis::Rosetta
---------------------------------------------------------------------------

Following is a summary of things that still need doing.  It is specific to
the Muldis-Rosetta core distribution only, and doesn't talk about things
that would go in other distributions.  (But, look at
lib/Muldis/Rosetta/SeeAlso.pod for a list of other related distributions
that should be created.)

The following list is loosely ordered by priority, but list items may
actually be addressed in a different order.  There is no specific time
table for these items; they are simply to be done "as soon as possible".

* Generally speaking, make a new release to CPAN once every week, assuming
the progress is non-trivial, so there are regular public snapshots with
nicely rendered documentation.

* Consider using Carp::Clan module, if it would be useful.

* Update Interface.pm and Engine.pm concerning that Muldis D no longer has
a bootloader concept, and regular Muldis D depots are used instead.
THE FIRST SENTENCE AFFECTS THE REST OF THIS TODO ITEM, WHICH IS OUTDATED.
Update Interface.pm to add a few specialized Process methods for loading
or dumping whole depots.  The first sort of exists already in the form of
execute() though that'll need to be able to take an entire depot content
declaratively, catalog plus data at once.  The second would be added and
would dump a whole depot catalog+schema.  This is different than what
reading the payload of a Value does, as it could dump a bootloader.  Note
that this and the next item suggests a bit of Muldis D language
enhancements are necessary.

* Reorganize the plan for Example.pm so that the same load and dump code is
used at both ends, both storage and application, since by default Example
depots are stored on disk as Muldis D source code describing the depot.  So
Util/Tiny.pm will also go away as it turns out other Engines should stand
to use something more efficient or dependency-requiring than Example would;
also, the version for Example is now to be simpler to not be streamable,
and just work where the source can all be in memory at once so parsing etc
is just on a normal Perl string variable.

* Implement the Muldis D metamodel, that is, the catalog.  This is the main
prerequisite for doing anything moderately more complex than what has
already been done, including the support for user-defined data types,
stored routines, constraints, virtual variables, and persisting databases.

* Flesh out the user-input validation code in the Example Engine, as is
appropriate, so that all bad input results in graceful failures rather than
ungraceful ones.

* Flesh out the various parts of the test suite.  There are currently 2
main parts envisioned:  1.  Several t/*.t files that test support libraries
of Example.pm in isolation.  2.  The Validator[|*].pm files which test
Interface.pm and the Example Engine as a whole, as well as being reused for
other Engine distributions.  Note that the core test suite should execute
in the above given order, so consider renaming the Validate Example test to
a higher number than 50 to make more room for others, such as to 80 or 90
or 99.

* Update the Example Engine to implement the rest of the relational
algebra|calculus operators, as well as all the reasonable operators for
other core data types: Bool, Int, Blob, Text, Rat.

* Update the Example Engine to implement persisting databases.  For
simplicity of implementation and learning, a whole depot will simply be one
file containing serializations of all the relevant Perl data structures
defining its catalog and data.  While this is very much non-scalable, the
Example Engine is not intended to be scalable, just provide the correct
semantics in the simplest way possible.  Other Engines will presumably do
persistence in an intelligent and scalable (and more complicated) manner.

* Update the Example Engine to implement the optional system-defined data
types: temporal, spatial.

* Optimize the Example Engine as can be done without making it too
complicated for its primary use as an Engine reference implementation /
learning tool.

* Judiciously add external dependencies (besides Perl itself) to this core
framework, at such times that a reasonable case can be made for it.

* Applicable to the Perl 6 version only:  Exploit additional Perl 6
features as they become implemented in Pugs and/or elsewhere, so to
simplify our own code, which currently does manually what Perl 6 should do
for us.  Examples being that if Perl actually enforces routine signatures,
we won't have to manually check our arguments as much as we do, or at all.

* Applicable to the Perl 5 version only:  Consider adding dependencies on
Module::Build and/or some better exception handling module.  Consider
raising the Perl version dependency to 5.10.1 from 5.8.1, to simplify
further dependencies.

* Whatever else needs doing, such as, fixing bugs.