September 26, 2005 · 1 comment
in Uncategorized
We had a great hacking session today, with Josh piped in over iChat and VNC from California, and King and I hunkered around his collection of Cinema Displays. We managed to replace our krufty jGenerator-powered flash file wrapper class with one based on JSwiff, in under a day.
JSwiff takes care of the nastiness of dealing with the .swf file format, and provides an extremely helpful XML intermediary – you can convert any .swf file to this xml format, modify the xml, then render back as .swf. Very handy for what we need to do.
Basically, all we do is a fancy search-and-replace for some custom tags (for things like the image – encoded in Base64 – and the tombstone fields for display on screen) in this intermediate xml file, then pass it into JSwiff and ask it to transform that xml into a swf that we can use in our finished presentation. It’s fast, and so far very reliable. As an added bonus, it appears to handle accented characters and such, which totally borked in jGenerator. Mavericks will look better now, once I regenerate all transformed assets.
And JSwiff doesn’t look like it will be affected by the scary deadlocks that made jGenerator basically useless for us. Yay, JSwiff! 
Even better, if this works out (it’s still being tested), then Pachyderm 2 is fully usable again, and on track for the October release!
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…
We’re using jGenerator for the Pachyderm project – to replace the abandoned Macromedia Generator product – for wrapping images in .swf files for display within Pachyderm presentations. The .swf files provide value-add stuff like “tombstone” data, and a lightweight, unobtrusive form of DRM.
However, jGenerator has been rather neglected for 3 years now, and as a result it’s starting to show cobwebs etc… Remember my friend Murphy? Largely a result of these cobwebs.
Today, days after we thought we nuked the jGenerator problem, it came back in full force. Building presentations would occasionally hang (sometimes not reliably, or sometimes very reliably). We tracked down the problem thanks to the handy dandy java debugger jdb (handy document on using jdb in a running WebObjects app), and it was the result of jGenerator using java.awt.Rectangle classes rather than java.awt.geom.Rectangle2D.
The methods had been altered to use Rectangle2D in the signatures, but were actually passing around Rectangle objects instead. This apparently causes problems on MacOSX and other Unix-like systems, as was discovered by the OpenLaszlo folks. They had to start their own fork of jGenerator 2.2 to fix this (and potentially other) problems. We just did the same.
We had another round of Team Programming at a Distance – the three of us brainstorming and hacking and researching. That is soooo much more fun and rewarding than copying and pasting…
Today, Murphy made me his bitch. He totally kicked my ass and made me call him “uncle”.
You may have won this round, but I’ll bring it, punk.
I had promised to have a fresh build of the Mavericks website ready for final review today, but jGenerator chose this exact time to decide to pack it in. It’s not working consistently, and I couldn’t publish a complete section of Mavericks. I spent the entire day trying to track down the reason for an external library to suddenly refuse to work, when I believe that nothing had changed. Obviously, my assumption about nothing having changed is wrong. I know what I’m doing over the weekend.
To top it off, I am so fried from having burned midnight oil while juggling what feels like a bajillion simultaneous urgent! highest priority! NOW! demands, that I don’t think I was exactly productive/effective at tracking down the cause of the problem today. Felt much like I was watching someone drowning, in slow motion. I knew what I had to do, but the neurons just weren’t firing as needed, or perhaps in the wrong order…
Thanks a lot, Murphy.
