Required skills: Python

Difficulty: Hard

Motivation

During the data conversion, the converter generates so-called export requests (MediaExportRequest) for media files. Currently, export requests store the filepaths for the source file and the to-be-generated target file as well as a save() function. save() is used to read the source file, convert it to a media format readable by openage and write the result to a file. For every media type, there is a subclass of MediaExportRequest with its own save() implementation.

There are problems with handling save() in the MediaExportRequest implementation: There can be a number of intermediary conversion steps between reading the source file and writing the target file, e.g. texture packing for graphics files. In the worst case, this can lead to a convoluted chain of operations with a workflow that is very hard to understand. For example, it can result in MediaExportRequest's save() function, calling the save() function of an intermediary format, which also calls save() on a subformat... We also run into the risk of creating circular dependencies and spaghetti code when extending the implementation.

Task

To adress these issues, the save() functionality should be implemented in a dedicated processor rather than in MediaExportRequest or any intermediary subformat. Instead of a convoluted chain, the processor function should have a linear workflow. All intermediary conversion steps should be initiated by the processor function.

The workflow should look like this:

1. Acquire source file path from MediaExportRequest
2. Read source file (using a service)
3. Handle any intermediary steps in linear order, e.g. texture packing or PNG creation
4. Write the end result to file

MediaExportRequest would be reduced to a storage format for information used by the processor.