launchpad-reviewers team mailing list archive

["Jeroen T. Vermeulen" <jtv@xxxxxxxxxxxxx>]

Jeroen T. Vermeulen has proposed merging lp:~jtv/launchpad/export-reorg into lp:launchpad/devel.

Requested reviews:
  Launchpad code reviewers (launchpad-reviewers): code


= Translations Export Reorg =

This branch rearranges how Translations exports files, to make way for a new hyperspac^H^H^H^H^H^H^H^H^H attempt at support for Mozilla XPI exports.

There were several things right with the export machinery, and several things wrong.

Right:
 * Isolated, away from the Launchpad database.
 * Centralized, with an Exporter utility.
 * Universal, thanks to a format-neutral data representation.
 * Data-driven, based on relationships between input & output formats.
 * Plugin-based, with "format exporters" for different file formats.
 * Generic, using a Strategy pattern to store output files.

Wrong:
 * Hard to use.  You had to look up your format exporter, then invoke it.
 * Duplicative.  The main "for each file in this bunch" loop is in each format exporter.
 * Irregular.  Format exporters know how to export (a) a message or (c) a bunch of files, but not (b) a file.
 * Ad-hoc.  The storage strategy object was created in each format exporter, but we'll want to give the caller a choice.  Committing to a branch might be a storage strategy.
 * Rigid.  All files you exported into a tarball had to be of the same format.

The fixes:
 * Have the central exporter do what you actually want—look up format exporters and (c) export a bunch of files.
 * Make format exporters able to export (a) a message or (b) a file.
 * Choose output format through a parameter to the central exporter, or let it default to each file's native format.
 * Store the format choice in the format-neutral representation of a file.
 * Give each format exporter knowledge of its file format and associated MIME type.
 * Let the caller pass a storage strategy object into the format exporter.

We'll want to make a few more improvements later:
 * Accept a storage strategy object as input to the central exporter's (c) export a bunch of files method, so that committing to a branch (or writing to a zip/jar/xpi archive) becomes a choice of storage strategy.
 * Associate MIME types with file formats rather than with format exporters.
 * Isolate the policies that assign filesystem paths to exported files.
 * Eliminate the separate implementation we have for language-pack exports.
 * Kill the [I]VPO[T]Export classes which essentially duplicate the format-neutral data representation.  (These were once introduced for optimization through database views, which later turned into an immense performance drag).

Can't cure all the world's ills in one branch though!

I eliminated as much lint as I could, mostly in a separate branch that's already landed.  I'll follow up with a separate lint aftercare branch though.

To test, run something like…
{{{
./bin/test -vvc -m lp.translations.tests
}}}


Jeroen
-- 
https://code.launchpad.net/~jtv/launchpad/export-reorg/+merge/30620
Your team Launchpad code reviewers is requested to review the proposed merge of lp:~jtv/launchpad/export-reorg into lp:launchpad/devel.