Where do Derivatives Belong in the D7 Media Ecosystem?

Inspired (guilted) by the recent discussions about private planning sessions on the development list and the number of posts to the How to help get Media to 1.0 release and beyond issue @tsvenson started back in January, I wanted to get this posted sooner rather than later. I've shown this graphic and discussed the structure with several people involved in large media sites, but most of these discussions have been happening in person or over email.

I'm mentoring Janez Urevc's Google Summer of Code Project for a Derivates API. Since this project has ambitious goals of both standardizing the way derivative relationships are handled AND a workflow for creating new derivatives, I've been concerned that the scope of the project might result in a large code base that lacks enough structure and stability to build on. There are a lot of features about the current Video project I like, the way the modules are being bundled is not one. I'm not a big fan of the "one big D.O. project to rule them all" approach. AlexUA used a great analogy when we discussed this. "Video is like the new Legos where your boat comes with one, big boat base piece". That approach works for some people, but many of us want the option to reorganize the parts in a different configuration. We want Legos with smaller pieces and a recommendation for how to put them together, but the freedom to turn our boat into a spaceship or a kitten killing robot. The really exciting part of this structure is with exportables and pre-configured profiles, everyone can get what they want when modules are broken up into projects that separate the Players and Engines.

Based on this strcuture, I've encouraged Janez to break his GSoC project up into 2 projects on Drupal.org...

1. Derivative API - This will be really simple, stable project. As the passive tense implies, the module will provide an optional API for other media related modules to track the relationship between files as well as the status of unfinished transcodes or transfers, but would not include any code to create a derivative itself. All information about the "finished" files themselves would be stored in the existing file_managed table and playback would be handled by the module that declared itself the handler for the streamwrapper. This module could provide some optional View handlers and an option to implement a cascading delete. The Derivative API could also be used to offer cascading display similar to what media_amazon is doing now in D7 and Storage API allowed in D6, but even that would be handled outside of the core API. The API needs to be simple and stable to be used as building block for a variety of Media configurations and adopted by other developers writing encoding/transfer "engines".
2. Derivate Workflow UI - This would be a D7 module similar to what media_mover's D6 config and steps, but instead of developing specific engines like ffmpeg_wrapper, engines could be used within a Derivate Workflow or as stand alone, with a simpler configuration. Engines should have the option of including their own interface similar to Video's FFMPEG implementation or what ffmpeg_converter added to ffmpeg_wrapper.

Derivate Workflow is likely were the majority of Janez time would go this summer. Obviously he'd need at least one "workflow enabled" engine to demonstrate all of the features in his GSoC proposal. The more support he gets from developers already familiar with transcoding and uploading with FFMPEG, ZenCoder, Internet Archive, YouTube, Vimeo, etc, the more time he can put into the API and Workflow project.

At some point in every project, the discussion about structure and strategy needs to end and the implementation begins. We are at that point as the GSoC mid-term evaluation period starts 7/11. I've asked Janez to show substantial progress on the Derivative API and post a decription for how an engine module would expose its configuration options to be used in a workflow before the midterm. That should give other developers code to start working with and a better idea of how all these pieces could fit together.

I feel like this is correct structure because it meets 3 criteria: users can start simple and add complexity as needed, backend encoding workflows can be swapped out with no impact on the design and layout, and the UI for the creating workflows work just as well when dealing with broadcast quality video as web sized video.

I believe the correct answer to where derivatives belong is between the Media framework and engine modules.