Why another module for SWF?

We originally were using swfobject, but swfobject and jQuery do not play nicely together. They both try to do things on page initialization that can clobber each other, we found. swfembed is, essentially, swfobject ported to use jQuery natively rather than trying to reimplement it.

The story behind the plugin...

Originally, we were using the swfobject_api module to develop Flashy, an open source Flash video player for Drupal. The work we were (and are) doing requires a lot of interaction between the Flash and JavaScript -- things like handling dynamic insertion of Flash files and associated configuration, firing transitions in the DOM base on Flash and stuff like that. The problem was, though, that swfobject (the JavaScript library) was not working well with jQuery, especially when it came to the ready vs. deferred load event handling (which was behaving differently on IE, FF, and Safari).

After agonizing over bug fixes for a few days, we threw in the towel and went hunting on jQuery.com for new plugins (this was sometime in 2008). We were dismayed to find that there weren't really any good options out there. The one that seemed to meet our needs actually had some structural difficulties that made it unworkable for us.

So in a couple of hours I wrote a custom jQuery plugin that fixed the bugs in swfobject/jQuery, but still handled all the weird edge cases that swfobject handles nicely (things like inserting param values after the page was loaded).

The Flashy module originally extended swfobject_api to make it more OO (which makes good sense given what we are doing). But once we replaced the plugin, it became evident that we had a candidate for a second module. So we abstract, rearranged, and created swfembed.

While swfembed was developed primarily to meet our own needs, our policy is to release any production-quality (non-customer-specific) modules back to the community. It's not that we're trying to compete with swfobject_api or swftools, or even re-invent the wheel just to show that we can. It is simply that we needed some capabilities that other modules didn't have. So we created something that did. (Again, the module was developed in 2008, but we don't release code until after we launch the associated website. That was this week. Looks like there are now even more jQuery plugins for SWF -- one created last month.)

Unless you've hit similar glitches in your code, I would guess that you would be happy staying with swftools. We probably won't ever expand it out to the degree that swftools has done. swfembed is a low-level library, and will probably always be so.