Looking to the Future of AssetHost

Thursday, May 31, 2012, at 04:31PM

By Eric Richardson

AssetHost Screenshot
Eric Richardson

Screenshot of a part of the AssetHost admin user interface.

When I left KPCC earlier this month, I left behind two systems that I was particularly proud of having developed: AssetHost, a Rails engine that serves up all of the station's web image and video assets, and StreamMachine, a Node.JS streaming audio broadcast system.

Both will live on, since the station was generous enough to allow me to open-source them. There's a thin line between a live open-source project and abandonware that just happens to have code online, though, so it remains to be seen whether either generates the kind of momentum needed to create a life beyond KPCC's uses.

The Vision

The idea behind AssetHost is a simple one: your CMS shouldn't have to know or care what kind of media you want to slap on a news story or blog post. It should just know what goes where and how to call the system that takes care of implementation. That system, AssetHost, is in turn based around the concept that regardless of media type, you're always going to need to create thumbnails and flat visual representations for things like homepages, section indexes and mobile devices.

The current generation of AssetHost does a good job of moving in that direction. We hooked the chooser and asset models into both Django and Rails apps with great success, and seamlessly integrated support for videos hosted on Brightcove.

But what if you took that idea to the next level?

A Future of Media Plugins

At the beginning of the year I wrote AssetGallery, the code that serves up the albums in my Photos section. It's a nifty bit of code, using AssetHost for image serving and turning out some galleries that look cool both on the desktop and on IOS devices.

What would be even cooler, though, is if AssetGallery was a plugin for AssetHost that created gallery assets out of image assets. Then you could go into the AssetHost admin UI, create a new gallery and use that gallery as an asset on a story without the CMS having to know or care that it is serving up a slideshow instead of a photo.

Or what if you had an "AssetMap" plugin that would take a geocoding and serve up a map as an asset, putting a nice interactive map UI on the story page and cutting thumbnail versions automatically to serve up in static contexts? That would sure seem a heck of a lot more useful than the map screenshots you too often see on breaking news stories.

The goal would be to have AssetHost act as a framework for these sorts of rich media, allowing plugins to be lightweight bits of code that just focus on their specific implementation.

Engines for Engines

What you basically end up with are engines that can be plugged into AssetHost in the same way that AssetHost can be plugged into your CMS.

Rails does a lot of the heavy-lifting on this already. The engine overhaul that came in Rails 3.1 is great, and both AssetHost and AssetGallery are written as mountable engines.

The trick that I'm still working to wrap my head around, though, is what an engine would need to do to export multiple routers. For instance, AssetGallery currently has a routes file that looks like:

AssetGallery::Engine.routes.draw do
  resources :sets do
    member do
      match '/:asset(/detail)' => "sets#show_asset", :as => :show_asset
      post :assets
    end
  end

  match '/' => 'home#index', :as => :home
end

That allows me to pull the gallery functionality into my site just by including one line in my site's routes file:

  mount AssetGallery::Engine => '/gallery', :as => :gallery

What I want for this AssetHost engine scheme, though, is to allow AssetGallery to also have a set of admin routes that it register with AssetHost, so that going to /assethost/galleries/ would give you an admin interface for galleries just like the one /assethost/assets/ would give you for other assets.

I have a feeling the answer lies somewhere in ActionDispatch::Routing::RouteSet, but exactly where has escaped my first few attempts.