Muldis::DB --------------------------------------------------------------------------- Following is a summary of things that still need doing. It is specific to the Muldis-DB core distribution only, and doesn't talk about things that would go in other distributions. (But, look at lib/Muldis/DB/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. * 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, Order, Int, Num, Blob, Text. * 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 version.pm and/or the Moose framework and/or Module::Build and/or some better exception handling module. Consider raising the Perl version dependency to 5.10 from 5.8.1, to simplify further dependencies. * Applicable to the Perl 5 version only: Consider lowering the Perl version dependency to 5.6 from 5.8.1, so that other projects which may become dependants of Muldis-DB and already work under 5.6 won't have to force Perl core upgrades. If this is done, the list of further dependencies will doubtless increase to include some things bundled with Perl 5.8, and/or Unicode may not work so well here. Note that this may likely only happen if Moose was adopted, in which case the minimum Perl version we support is the same as the minimum that Moose supports. * Whatever else needs doing, such as, fixing bugs.