The Pachyderm project uses jGenerator to wrap images in a flash .swf container for display in the final product. That process does a few things that are pretty handy:
- Makes loading the images into flash easy - it's just loading more flash...
- Lets us embed metadata in a "tombstone" display field, much like the cards displayed in a museum. These tombstones travel with the asset, and can be displayed automagically wherever appropriate.
- Provides a lightweight DRM - the images are useless outside of the finished Pachyderm presentation (unless you're able to decompile flash, or take screenshots) - it's not an overbearing DRM, just a way to make it easy to be honest.
(left) tombstone in "closed" state. Click the arrow widget dealie to expand it to view the full tombstone (right)
But, we've reached a point where a bit of a dilemma has been forced upon it. Josh was describing it as Gordian today, and I think the solution might be as radical as that.
The jGenerator library that we use to wrap images in .swfs has been acting more and more flakey over the last few weeks. Likely a result of increased load, we're seeing what may be some kind of funky threading or deadlock issues deep in java.awt classes, which are relied upon for jGenerator to do its magic.
So, here's our dilemma:
- Keep on using jGenerator, Hoping For The Best™ - we'd add some debug/babysitting code to detect the deadlock issue, and attempt to recover from it.
- Switch to the OpenLaszlo fork of jGenerator, hoping that they may have resolved whatever issues are plaguing it. That's kind of a blind faith option, since we don't know if/how the Laszlo folks have modified jGenerator in their fork.
- Take the sword to the knot, and dump our legacy tombstone/drm/swf-wrapping implementation. Build a new one, from scratch, waaaay past the 11th hour. We know what we would need to do in the authoring application to support a much more robust and flexible metadata-embedding-and-display strategy. The idea that we've come up with is actually more useful in many ways, as it can be applied to any media type - not just .swf-wrapped-images. We could easily create an XML-based lookup table that the flash templates would have to consult to gather metadata about assets in a presentation. That's actually pretty straightforward to do in the authoring app, but every flash template file will need to be modified to teach it about the tombstone xml lookup...
I'm leaning quite strongly toward the third option. Let's dump the bottomless pit of jGenerator, and focus on the future. There may be a short-term solution - drop tombstones altogether for awhile, taking some time to design the new solution without rushing it. We'd have to keep a snapshot of Pachyderm running, since Mavericks relies pretty heavily on tombstones - but even that needs to be fixed, since jGenerator barfs on characters like accents...
Basically, nobody's comfortable with the status quo - it's not stable, is unreliable, and can lock up publishing altogether. The Laszlo option might work, or it might not, leaving us no further ahead. The xml-lookup option is the most solid design, but would take more time than we have. Stupid dilemmas...
Update: Chatting with Josh last night, and he came up with a potentially simpler solution. No need for a lookup table, just have one xml file per media asset - change the filename from .jpg or .mov or whatever to .xml and you have the xml definition of the tombstone for that asset. No xml file, no tombstone. Actually, that could give us a bunch of flexibility - different types of tombstones for different sizes of an asset, for instance. This would be relatively trivial to implement in the authoring app, but we need to figure out what it would take to implement something like this in the flash templates...