=pod

=encoding utf8

=head1 NAME

Muldis::Rosetta::SeeAlso -
External resources that you really ought to look at

=head1 VERSION

This document is Muldis::Rosetta::SeeAlso version 0.5.1.

=head1 DESCRIPTION

This document is a central location within the L<Muldis::Rosetta>
distribution where any important recommendations of or links to external
resources go.  This includes both resources that were helpful in making
Muldis Rosetta, as well as resources that are or could be related to Muldis
Rosetta.

=head1 FORMAL SPECIFICATION

Please see the separately distributed L<Muldis::D> distribution, which
defines the B<Muldis D> language that Muldis Rosetta implements and uses as
its primary API.  Likewise see also the L<Muldis::D::SeeAlso> appendix
document of the Muldis D spec for links to various things comprising and
related to I<The Third Manifesto>, which Muldis Rosetta is a formal
implementation of by way of Muldis D.

=head1 LIST OF PUBLIC MULDIS ROSETTA ENGINES

I<This documentation is pending.>

L<Muldis::Rosetta::Engine::Example>.

=head1 PROSPECTIVE MULDIS ROSETTA EXTENSIONS

These are some theoretical examples of other Perl modules or documentation
that could be created to work with Muldis Rosetta, but if so would most
likely be distributed independently from it.  The given package names are
examples, and the examples in question could have other names if
appropriate.

=over

=item C<Muldis::Rosetta::Cookbook(|::\w+)>

Pod files with a potentially large collection of examples, tutorials, FAQs,
and so on that help people learn how to employ Muldis Rosetta for the
things they need to do.  In particular, there should be a lot of help given
for people migrating from other systems that use different paradigms than
Muldis Rosetta does, for example SQL-using systems.

The Cookbook distro may also be the main repository of executing code that
would otherwise go in the /examples directory of the Muldis Rosetta core
distro.

=item C<Genezzo> or C<Genezzo::Muldis_Rosetta> or
C<Muldis::Rosetta::Engine::Genezzo> etc

A Muldis Rosetta Engine built around Jeffrey Cohen's L<Genezzo> DBMS, or
specifically the root module that provides the C<new_machine> function,
could conceivably have either of the above file or package names, depending
on what its author prefers, or something else yet.  A strong name influence
could be whether Muldis Rosetta forms the sole public interface for Genezzo
after its conversion to use it, or whether Genezzo would retain alternate
public APIs that work without Muldis Rosetta being present on the system.
If Muldis Rosetta is Genezzo's sole or primary interface, then simply
C<Genezzo> is probably best for branding.

=item C<Muldis::Rosetta::PHDMD::Refactor(|::\w+)>

Utility modules that take Perl Hosted Data Muldis D (PHDMD) code as input
and derive other PHDMD code as output, such as with the purpose of
refactoring them into canonical representations (such that manual code
debugging or comparisons may be made easier), or forms that are more
efficient for particular uses but are still logically equivalent.

Presumably all of these would work using static analysis methods and not
actually "execute" anything, so they are independent of any particular
Engine environment.  This isn't to say that we can't separately have
modules that help implement a specific Engine and do PHDMD optimization
that knows the specific needs of that Engine's implementation environment.

Other words that could go in such module names are like C<Optimize> or
C<Canon>, or whatever authors prefer.

=item C<Muldis::Rosetta::PHDMD::YAML> and C<Muldis::Rosetta::PHDMD::XML>
etc

Utility modules that serialize Perl Hosted Data Muldis D code to, or
unserialize it from, logically equivalent YAML, XML, or other generic data
interchange formats.  This implementation should be native to the Muldis D
language itself and not output any Perl-specific details that aren't in
non-Perl languages, so that it is suitable for interchange, at the very
least between Perl 5 and Perl 6.

=item C<Muldis::Rosetta::PHDMD::Translate::PTMD>

Utility module that parses Plain Text Muldis D (PTMD) code into Perl Hosted
Data Muldis D, and also that generates the former from the latter.  The 2
formats should basically have a 1:1 correspondence.

=item C<Muldis::Rosetta::Shell>

Implementation of a command-line user application over the Muldis Rosetta
API that takes Plain Text Muldis D as input, compiles it and runs it, and
nicely formats output for user display.  This is analogous to
L<DBI::Shell>.

=item C<DBD::Muldis_Rosetta>

A wrapper over the Muldis Rosetta API that makes it work as a L<DBI> driver
module, should that be useful.  Depending on what DBI itself permits or
requires, this could take a variety of query definition formats, including
either or both of Plain Text Muldis D or (most likely) Perl Hosted Data
Muldis D.

=item C<Muldis::Rosetta::PHMD::Translate::Tutorial_D> etc

Utility module that parses the B<Tutorial D> language into Perl Hosted
Muldis D code, and also that generates the former from the latter.  Mainly
this is just by-the-book using the grammar published by Darwen and Date,
but it could also handle compatible extensions by other B<D> language
implementations.  In addition, separate utility modules can be made which
translate to and from other B<D> languages that don't look like B<Tutorial
D>.

=item C<Muldis::Rosetta::PHDMD::Translate::SQL::Native>

Utility module that parses a Muldis Rosetta-native variant of SQL into Perl
Hosted Data Muldis D, and also that generates the former from the latter.
This SQL variant is essentially a cleaned up subset of the SQL:2003
standard, with some misfeatures removed, some missing features added, and
some alterations common in other SQL DBMSs substituted or added.  Or
alternately, it is like a subset of Muldis D made to look as much like SQL
as possible.  This Muldis Rosetta-native SQL variant always has distinct
column names in rowsets, requires matching column names for inputs to
union/intersect/etc, never stores or results in duplicate rows, always uses
2-valued logic (not (>=3)-valued logic), and has case-sensitive
table/column/etc names and character strings.  An application written to
use this SQL dialect rather than some other dialect should behave more
deterministically, and perform faster, than ones written to some other SQL
dialect, since there is less indirection involved between what users query
and what actually happens to implement it.

=item C<Muldis::Rosetta::PHDMD::Translate::SQL::\w+>

Utility modules that parse other variants of SQL (or subsets thereof) into
Perl Hosted Data Muldis D, and also that generate the former from the
latter.  Examples of these variants are the actual SQL:2003 standard, and
the native dialects of each actual SQL DBMS.

=item C<Muldis::Rosetta::PHDMD::Translate::\w+>

Utility modules that translate data (including code and declaratives)
between representations that are Perl Hosted Data Muldis D and
representations that aren't, or between 2 of the latter kind while using
the former kind as an intermediate representation.  Besides the
aforementioned possibilities that deal with B<D> languages or SQL, we can
have utilities that translate to/from native Perl data structures,
including native Perl routine definitions (L<PPI> would probably be
employed in the Perl 5 version), and including commonly used third party
class' objects.

=item C<Muldis::Rosetta::Proxy::(Server|Client|\w+)>

Implementation(s) of a generic proxy server plus client for the Muldis
Rosetta API, letting the normal Muldis Rosetta Engine and the user
application reside in separate processes.  The client would do
C<Muldis::Rosetta::Interface> roles and the server would be an application
or server-extending plugin that sits on top of the Muldis Rosetta API.  Or
whatever implementers want to do.  This is analogous to proxying modules
for DBI or other DBMSs.

=item C<Muldis::Rosetta::Engine::(SQLite|Postgres|Oracle|\w+)>

A default (but not mandatory) namespace for Muldis Rosetta Engines to go,
that provide the C<new_machine> function and do the
C<Muldis::Rosetta::Interface::\w+> roles.  A lot of these would likely be
implemented over existing DBMSs, which results in Muldis Rosetta being an
alternative API for them.

=item C<Muldis::Rosetta::Engine::DBI>

A Muldis Rosetta Engine built around the Perl DBI module in a more generic
fashion, that would work with multiple DBD modules rather than being
specific to one SQL DBMS, could be named this.

=item C<DBIx::Class::Storage::Muldis_Rosetta> etc

An alternative plug-in storage engine for L<DBIx::Class> that uses Muldis
Rosetta rather than DBI.  Analogous extensions can be added to other DBI
wrappers modules such as L<Tangram> or L<Rose::DB> or what have you.  In
either case, said alternatives can either be bundled with the core distros
of those other modules, or separately from them, as per their authors'
preferences.

=item C<Muldis::Rosetta::Emulator::(DBI|JDBC|OCI|\w+)>

Emulations of other modules or APIs as wrappers over Muldis Rosetta.  This
is potentially the easiest way, short of the other modules themselves being
appropriately updated, to permit migration for legacy apps to Muldis
Rosetta while they have the fewest actual code changes.  The emulators
would likely employ SQL translator utilities internally.

=item C<MuldisX::Rosetta::\w+>

Unofficial extensions to Muldis Rosetta could be named in this space,
though it doesn't have to be used if prior coordination happens between
developers; moreover, this namespace is likely to be used even by the main
Muldis Rosetta developers to experiment with possible extensions without
tying up a "good" namespace for them.

=back

=head1 PUBLIC SOLUTIONS BUILT OVER MULDIS ROSETTA

I<This documentation is pending.>

These Perl 5 applications and frameworks are, perhaps, at the front of the
line to get Muldis Rosetta bindings: L<Jifty>, L<Catalyst>, L<Maypole>,
L<Bricolage>, L<RT>.  Generally speaking, the more active the development
or the more popular the project, the higher the priority to support it.

=head1 DBMS-RELATED PERL MODULES

I<This documentation is pending.>

These other Perl 6 packages also work in the problem domain of managing
data or data definitions or connections to databases:

L<Set::Relation>, L<Set>.

These other Perl 5 packages also work in the problem domain of managing
data or data definitions or connections to databases (list not exhaustive):

L<DBI>, L<Tangram>, L<DBIx::Class>, L<HDB>, L<Class::DBI>, L<Pixie>,
L<Alzabo>, L<DBIx::SQLEngine>, L<Rose::DB>, L<SPOPS>, L<Set::Object>,
L<Set::Scalar>, L<Object::Relation>, L<Oryx>, L<DBM::Deep>,
L<DBIx::SearchBuilder>, L<DBIx::RecordSet>, L<DBIx::Abstract>, L<DBIx::IO>,
L<DBIx::AnyDBD>, L<DBIx::Browse>, L<DBIx::DBH>, L<MKDoc::SQL>,
L<Data::Transactional>, L<DBIx::ModelUpdate>, L<DBIx::ProcedureCall>,
L<DB::Ent>, L<DBIx::Romani>, L<DBIx::DBSchema>, L<DBIx::Namespace>,
L<TripleStore>, L<Data::Table>, L<ORM>, L<OOPS>, L<Object::Transaction>,
L<Relations>, L<DBIx::SimplePerl>, L<DBIx::YAWM>, L<Class::Entity>,
L<SQL::Statement>, L<SQL::Parser>, L<SQL::Translator>, L<SQL::YASP>,
L<SQL::Generator>, L<SQL::Schema>, L<SQL::Abstract>, L<SQL::Snippet>,
L<SQL::Catalog>, L<DBIx::Perlish>, L<DBIx::StORM>, L<Tao::DBI>, L<NTuples>,
L<DBIx::CopyRecord>, L<Data::Domain>, L<Fey>, L<SQL::Tokenizer>.

=head1 AUTHOR

Darren Duncan (C<perl@DarrenDuncan.net>)

=head1 LICENSE AND COPYRIGHT

This file is part of the Muldis Rosetta framework.

Muldis Rosetta is Copyright © 2002-2008, Darren Duncan.

See the LICENSE AND COPYRIGHT of L<Muldis::Rosetta> for details.

=head1 TRADEMARK POLICY

The TRADEMARK POLICY in L<Muldis::Rosetta> applies to this file too.

=head1 ACKNOWLEDGEMENTS

The ACKNOWLEDGEMENTS in L<Muldis::Rosetta> apply to this file too.

=cut
