Spam: The other white meat

As Media Mover 2 finally moves toward alpha, I've taken the risk of doing some significant refactoring- or at least improvements- to make the transition to Drupal 7 easier as well as to provide a much more robust platform people to start leveraging.

Similar to Drupal 7's hook_file_load, Media Mover now offers hook_media_mover_file_load() and hook_media_mover_file_save(). This allows for easy altering of files as they pass through the system. These are both cache aware so you can still benefit from caching while having the ability to avoid modifying a cached file if your modifications are not dynamic (cached Media Mover files have $file->cached set). Steps and configurations are also alterable on load and save.

Media Mover 2's S3 implementation now supports private files hosted on Amazon. You can set access to files by role- with the obvious exception of the anonymous user. Links to each file expire after a set amount of time which gives site administrators a degree of control for providing protected content.

With folks using Media Mover to transcode larger and larger video files, cron time outs have become somewhat of a problem as Drupal waits for FFmpeg to complete its processing. With Media Mover one, configurations are run from cron by default (not required, but out of the box) which means that cron runs as long as the Media Mover configuration takes. While it is possible to limit cron runs, the reality of transcoding a gigabyte file is that it takes time regardless of how much horsepower you can throw at it. Media Mover one was setup to be friendly to multi-machine systems, but the system left some things to be desired.

The S3 module for Media Mover just got updated to make the CDN integration easier. As files come through the system, files which already reside on S3 will have $file->s3_uri set which allows theming functions to display the local URI if it is present or the S3 URI if the file is already on S3.

Make that $file->s3_data which is a serialized array of data from the S3 file. This allows for the generation of private urls.

Media Mover 2.x has been slowly creeping along for the last bunch of months and is starting to approach an alpha state. One of the cool things about Media Mover 2 is that the architecture has been rewritten from the ground up. Now there are three main concepts - files that Media Move knows about, configurations which are a collection of steps, and steps which are settings for some kind of action or process that is done to a file. However, they all have lives of their own which means you can do some neat things with them.

Let's imagine that you have a module that needs to do some kind of file processing that Media Mover already supports. You can define a step- that is, a set of settings - much like a view - in code in your module. You can then invoke it simply:

Frost posted some nice documentation on FLV Media Player

beksau posted a really helpful tutorial on how to integrate mobile technology (eg: mobile phones) with Media Mover to create an automatic transcoding system for posted content. Beksau's process uses mailhandler as a standalone rather than integrating directly with Media Mover, but from my perspective, it just showcases the fact that you can make very creative systems for handling content- Media Mover is flexible enough to plug in to what you are already using.

As I've been working on getting the 6.2x branch of Media Mover up and running, I've started going through the old code and cleaning up the Doxygen documentation so that my own documentation effort is a bit cleaner. I'm now generating daily snapshots of all three branches here: doxy documentation

UPDATED

After some consideration and discussion with Robin I think my first go at hook_media_mover is off the mark. Using hook_menu as the template, I think the process of defining media mover actions can be simplified:

function mm_node_media_mover() {
  $items = array();
  $items['set_node_status'] = array(
    'description' => t('Set node status'),
    'configuration' => 'mm_node_config_complete',
    'callback' => 'mm_node_complete',
  );
  return $items;
}

$items[NAME] identifies the specific action. The individual items for each action- description, configuration, callback, harvest provide information about what to do with this action.

In an attempt to improve the workflow of Media Mover, I'm going through the process of refining the main API aspect. The main reason for this is to move away from the 4 step model (harvest, process, store and complete) to a chainable set of definable actions.

These are some notes to self as I'm going through the process, but feedback is of course appreciated

function hook_media_mover() {
  return array(
    '#name' => t('My Media Mover module description'),
    '#actions' => array(
      array(
        // give each action in your module a unique id 
        '#action' => 'operation_1',
        // give your action a description
        '#description' => t('Do something with a file!'),
        // harvesting files is a special case. You only need