MediaTypeRefactor/DesignDoc

= Media Types Design =

This document is based on requirements/wishes listed in http://wiki.mediagoblin.org/MediaTypeRefactor


 * Note*:  * Attachments have deliberately been excluded from this document to reduce complexity

= Publishing clients =

These are described optimal behaviours of different types of publishing clients.

*n*-file with media metadata
GStreamer `gst-launch` inspired exclamation-mark-separated "elements" of media entries:

*n*-file

 * Note*: Requires browser drag and drop support.

* What about publishing-metadata?
 * Note*:  * What if there's folders in there?

Single-file
Could be used as fallback for browsers not supporting drag and drop.

API
TBD

= Media types =

Installation
* What about dependencies such as GStreamer and related packages? We could include that in our wrapper, but it'd have to take into account all the different distributions' package managers out there.
 * Note*:  * We could build a wrapper around pip that performs the installation steps automatically.

Negotiation
Media type negotiation is done per-file by iterating through a registry of enabled media type plugins. Several negotiation mechanisms may exists, such as a cheap file-extension based one and a more expensive file content sniffing negotiation step.

Output files
Some media types such as ASCII art and images might have a very simple data structure:

Media types such as `video` and `3D object` might have more complex output files:

we should therefore allow a lot of flexibility for the files

= Media processing =

Processing takes the original file and creates files of lesser size/quality that The pipeline is as follows:

# The application receives a bytestream, optional byte stream metadata (i.e. filename) and publishing-metadata. The bytestream and bytestream metadata is sourced from the *original file*. * Possibly we could have "adapters" of some sort that provides this data consistently across publishing clients.
 * Note*: Some users have expressed a wish for mediagoblin to simply read a folder with files and create a "web album" from them.

* The media type negotiation mechanism decides one or more suitable media type plugins to handle the conversion of the *original file*, pushes task data to the task broker and creates a *MediaEntry* in the database and populates it with at least the media type. * The task handler now checks the task broker for a new task when received the task handler looks up the processing method for the selected media type and runs it. * The media processor converts the *original file* into smaller, displayable media. These media files are then placed in the *public storage*.


 * Note*:  * Are there cases where we should accept more than one input file?