Posted by bangpound@drupal.org (not verified) on February 9, 2009 at 3:04pm
Excellent. Someone enabled comments on this post, so I can delete my previous discussion topic and engage here.
SWFObject, SWFObject API are definitely duplicates.
SWF Tools provides a multifaceted feature set, which includes duplication of the features of the two SWFObject modules above. However, it also includes media player supports -- flowplayer, JW FLV player, 1bitaudio, simpleviewer -- and other embedding methods.
I wouldn't say that SWF Tools is a clear duplicate of the other two modules, but I do see significant feature overlap.
I don't know if swfobject.js is the best and greatest SWF embedding script, but it is hosted by Google AJAX Libraries API so there's probably a ton of people using it. jQuery Media plugin provides similar but not identical functionality. There are other scripts that embed flash, too: flashembed.js and the others supported by SWF Tools.
Many modules embed flash, usually video, and often include their own copy of SWFObject.js. Just search the CVS repository for copies of swfobject.js.
These duplicate/overlapping modules provide a base for other modules to use. Does that mean that other modules which don't rely on these fundamental modules should be listed as having duplicate functionality too? Do module authors avoid using one of these library modules because there are two or three options to choose from?
I'm going to nitpick here and argue that these modules have little to do with one another. The SWFObject module incorporates blocks and other functionality for flash embeding. The SWFObject API module is an API only module- designed for other developers to utilize, something that the SWFObject module doesn't really do- their end usage is vastly different.
In my mind, this is what the SWFTools module is trying to accomplish, albeit on a much broader scale. In this case, I think there is actually a much larger overlap with SWFObject API and SWFTools. I ultimately think that SWFObject API needs to be subsumed by SWFTools, however, there needs to be a compatibility layer so that existing modules which depend on SWFObject API can transition seamlessly. I've roughly proposed this here: http://drupal.org/node/135063#comment-1247053
I'm not the maintainer of SWF Tools anymore, given time pressure from running a business. I can express some thoughts about what I learned from SWF Tools.
With SWF Tools I created a great generic rendering module, it could handle any flash embedding you can think of, allowing people to write their own plugin extensions. I had proof of concept for sIFR, and even non-flash embedding like Quicktime. In the end I saw the opportunity for generic rendering. In fact if you want to talk duplication see this post.
At the time of writing SWF Tools I tried to make other tools obsolete, and I tried to team up with some of these other modules to do so.
Anyway, what I learned.
Lesson 1
Collaboration takes time, it falls into the same bucket as anything in open source. We can encourage people to write patches, but we can't make them. Pointing out duplication is useful, but I don't believe that a "shame" group is any more constructive than shaming my mum for not writing Drupal documentation.
Lesson 2
Big modules that do everything are not naturally better than small modules. Sometimes they are awesome (like Better Formats) but if people look at them and see cruft or redundancy for their project, then you may as well douse the fire and fold up your camping chair. On the first comment of the link above, Zen brought this home for me.
Lesson 3
Some duplication (or overlap) should be accepted as a natural part of a healthy open-source eco-system. OK, we've heard that before. But looking at the initial list, I would include things like Dynamic Rendering which re-implements flash embedding in contrib (for the sIFR plugin). (Actually perhaps sun started this wiki page after trying to find SWF Object support from another contrib module ;)
But of course, I have no problems with Dynamic Render, or the sIFR module before that. These modules handle a small task well, they are mostly unique, and at the end of the day people choose to use what serves their purpose and works well.
What I would love to see in core is a rendering library for embedding stuff. It would provide plugins (or allow people to provide their own) for crazy stuff like SVG and Canvas. If anything like that ever happens, we have a rich field of ideas and approaches to borrow from, and no-one who contributed to the planting/watering/etc should be shamed in any way!
Thanks for this pointer, sime! I've added this link to the wiki page (yes, it's a wiki page, so everyone can update it).
I started this thread after having asked in Drupal's IRC channels for a working, maintained, and future-proof Flash embedding module. No one was able to tell me the status of any of those modules.
I worked with SWFObject API before, but now need to create a Panels content-type, so (administrative) users are able to insert Flash movies as content into their panels (as pane). This means I want to contribute and improve what's there with a nice patch.
Then, I read the project page of SWFObject API, which clearly states that it is an API module only (so probably down to zero chances for getting my patch in maybe?). And it refers to swfobject module for user-facing stuff, which is completely outdated. No mentioning of SWF Tools at all.
However, knowing your efforts on SWF Tools, I looked up its status, too. Bad or good news: A new maintainer. But also, no note about related modules and why I'd want to choose SWF Tools.
Read the handbook pages about SWF Tools afterwards, which basically told me that SWF Tools provides the same SWFObject method as SWFObject API module does.
Still no clue about which module I should write a patch for. :(
Next best guess was to look at the issue queues of both modules. Usually, one of the involved modules is not maintained as well as the other(s). However, no luck here - both seem to be maintained fine.
Looking through your issues queue, I think I've covered most of the problems your users have raised.
...and this is the real cause for why these duplicate efforts are bad -- not only for both modules, but also for all Drupal users. Since both of you are/were module maintainers, I don't think that I need to explain why, or what I mean in detail here.
So this is my story. I want to contribute, but I still don't know where.
I believe the way out here would be to fix the other modules to use the API module for their engines. That takes out the code replication, and makes them all easier to maintain. Then going forward, your case would be (yes) another module, which also uses the API. I believe that developers are (sometimes slowly) learning that modules in Drupal can work together as building blocks, and this is a good analogy to explain to new users trying to understand the otherwise confusing world of contrib.
I think SWF Object could be ripped out of SWF Tools. (In theory there are a number of embedding methods that SWF Tools could handle, in practice there was only one most people use
Note: SWF Tools uses some jquery to walk the DOM and activate SWFObject as needed, rather than spit out activation code for every instance of an embedded object, so as long as that was available in SWFObject API ...
Ironically I wrote SWF Tools before messing with views and CCK, what a conundrum! But the structure is still sound, because the idea of SWF Tools is that you have associated file types with embedding methods - therefore a cck handler for filefield would should simple call something like:
<?php // off my head // SWF Tools knows about default parameters for the flash tool you're embedding // per the settings, but also allows you to override them, say if an alternative // value was set in a field handler options. if ($output = swf($node->somefield[0]['filething'])) { return $output; } else { return theme('however_filefield_does_it_normally', $node->somefield[0]['filething']); } ?>
Panels and views are no-brainers then since they work with CCK handlers. But you could also just write your Panels plugin and tell if some extra parameters.
And here are the downsides of SWF Tools from when I was last in the head space:
the name. SWF Tools. It's really just a generic file/object embedding routine. But I chose my namespace to avoid bloat.
there is a little cruft, but I did provide the new maintainer with a modified version before he took it over (which was a bit too invasive to just dump and run), but didn't follow up to see if he'd used it.
some other rough bits that highlighted gaps in my dev skillz
The overlap between the specific SWFObject module in SWFTools and SWFObject API is really close. They both function the same way, just that their theme functions are slightly different. I do like the idea of having a consistent embedding module(s) that all contrib can make use of, though the question of broader modules verses targeted modules is one that I'm not quite sure how to weigh in on. I think it'd be good if we can get Stuart in on this conversation- I contacted him but have not heard back yet.
I doubt it would be very hard pull out the swfobject stuff.
Just wondering how does SWFObject API handle many embeddings on a page? A lot of modules, a while back anyway, would simply repeat the same embedding javascript for each swf. But it should be done with a couple of lines of jQuery.
Actually, SWFObject API use a bit of javascript to create multiple embedded objects- theme_swfobject_api() and swfobject2_swftools_embed() are basically the same with a few exceptions. Which probably makes the argument for duplication that much more accurate :)
While I complete agree with Sime that large modules are not necessarily better, Aaron is dead on for pointing out that the overwhelming number of choices makes contrib more difficult for people to navigate. While I'd like to hold on to having an API only module for SWFObject, I am persuaded that it makes more sense at this point to integrate with SWFTools which has a similar API function. If there is a higher adoption rate and clearer implementation, then I think integration is in order. I've contacted Stuart and proposed a compatibility layer to make the transition easy for adopters of SWFObject API. Perhaps one approach is to add maintainers for the specific aspects of these larger modules to help keep the work load down.
Flash is a specific implementation that renders content in a specific player. I think this ought to be an extension of other modules (specifically: http://drupal.org/project/embed)
Swfembed and Embed do seem to be trying to do similar things.
Guys, I am not a contributer, partly because of time constraints and partly because of the high bar one has to reach to be able to. This bar is growing higher all the time because of duplication/multiplication issues like those discussed above. I think this selfish gene approach is stifling Drupal open source development. It is still relative early days for Drupal, but the quagmire is growing ever deeper - making it harder and harder to work with - and this will eventually put people off using it or contributing to it. But you know this already.
A point that I would like to make, that I don't think has been made clearly enough above, is the module user conundrums. As a module user, I spend way too much time trying to find the right modules and trying to understanding the differences between similar/overlapping/competing ones. The commonplace lack of clear descriptive documentation - even about what the modules do - let alone how to use them - makes the task many times more complex and long-winded than it need be.
It seems to me that Drupal has become too much a free-for-all and it needs far more peer review, discipline, standards, and vision. Great open source software - like the LAMP group - are not free-for-alls. They are extremely stable, disciplined, and they evolve - forwards. This is directed evolution.
It seems to me that is it too easy to contribute to Drupal, and Drupal is getting deluged with low quality stuff and documentation - among islands of excellent work. A stringent process of peer review, with voted subject-matter-experts as chairs of focus groups needs to be put in place. It is vital that the focus groups should have technical as well as non-technical members - probably 50-50. Just not being able to contribute a module unless a peer-review group has accepted the documentation - from both a descriptive and a technical standpoint - would be a huge step forward. If such groups and processes are in place, as a relative newbie, I am not seeing much of the benefits...
Michael, with regards to trying to select between overlapping modules, that's one of the reasons for the existence of this GDO group. If you notice there are several modules which do X and you're not sure which one will be most competent for your needs, search this group for threads about it, and failing that, start a new one. I recently did so when considering modules to provide a physical address CCK field, and the discussion was very helpful in helping me decide the approach to take.
As for requiring peer review before modules are submitted, there are two obvious problems with that idea. One is the amount of manpower it would require, and of course some "focus groups" would have more interested people or more competent people than others. The other is, of course, that quality is subjective. And it's really not too much of a tragedy for bad or incomplete code to be put up on D.o, if it's intended to be improved later; "release early, release often" is an open source software development credo.
Comments
Additional information
Please see the following threads:
http://drupal.org/node/135063#comment-1247053
http://24b6.net
http://24b6.net
overlapping functionality instead of duplication
Excellent. Someone enabled comments on this post, so I can delete my previous discussion topic and engage here.
SWFObject, SWFObject API are definitely duplicates.
SWF Tools provides a multifaceted feature set, which includes duplication of the features of the two SWFObject modules above. However, it also includes media player supports -- flowplayer, JW FLV player, 1bitaudio, simpleviewer -- and other embedding methods.
I wouldn't say that SWF Tools is a clear duplicate of the other two modules, but I do see significant feature overlap.
I don't know if swfobject.js is the best and greatest SWF embedding script, but it is hosted by Google AJAX Libraries API so there's probably a ton of people using it. jQuery Media plugin provides similar but not identical functionality. There are other scripts that embed flash, too: flashembed.js and the others supported by SWF Tools.
Many modules embed flash, usually video, and often include their own copy of SWFObject.js. Just search the CVS repository for copies of swfobject.js.
These duplicate/overlapping modules provide a base for other modules to use. Does that mean that other modules which don't rely on these fundamental modules should be listed as having duplicate functionality too? Do module authors avoid using one of these library modules because there are two or three options to choose from?
SWFObject != SWFObject_api
I'm going to nitpick here and argue that these modules have little to do with one another. The SWFObject module incorporates blocks and other functionality for flash embeding. The SWFObject API module is an API only module- designed for other developers to utilize, something that the SWFObject module doesn't really do- their end usage is vastly different.
In my mind, this is what the SWFTools module is trying to accomplish, albeit on a much broader scale. In this case, I think there is actually a much larger overlap with SWFObject API and SWFTools. I ultimately think that SWFObject API needs to be subsumed by SWFTools, however, there needs to be a compatibility layer so that existing modules which depend on SWFObject API can transition seamlessly. I've roughly proposed this here: http://drupal.org/node/135063#comment-1247053
a.
http://24b6.net
http://24b6.net
I see your point about
I see your point about SWFObject. It's also important to note that SWFObject is a D4.7 module and SWFObject_API is D5 and D6.
overlap yes
I agree about the overlap between SWFObject API and SWFTools. And there lies the rub. Why would you use SWFTools if all you wanted was SWFObject?
i won't collaborate on shaming!
I'm not the maintainer of SWF Tools anymore, given time pressure from running a business. I can express some thoughts about what I learned from SWF Tools.
With SWF Tools I created a great generic rendering module, it could handle any flash embedding you can think of, allowing people to write their own plugin extensions. I had proof of concept for sIFR, and even non-flash embedding like Quicktime. In the end I saw the opportunity for generic rendering. In fact if you want to talk duplication see this post.
At the time of writing SWF Tools I tried to make other tools obsolete, and I tried to team up with some of these other modules to do so.
Anyway, what I learned.
Lesson 1
Collaboration takes time, it falls into the same bucket as anything in open source. We can encourage people to write patches, but we can't make them. Pointing out duplication is useful, but I don't believe that a "shame" group is any more constructive than shaming my mum for not writing Drupal documentation.
Lesson 2
Big modules that do everything are not naturally better than small modules. Sometimes they are awesome (like Better Formats) but if people look at them and see cruft or redundancy for their project, then you may as well douse the fire and fold up your camping chair. On the first comment of the link above, Zen brought this home for me.
Lesson 3
Some duplication (or overlap) should be accepted as a natural part of a healthy open-source eco-system. OK, we've heard that before. But looking at the initial list, I would include things like Dynamic Rendering which re-implements flash embedding in contrib (for the sIFR plugin). (Actually perhaps sun started this wiki page after trying to find SWF Object support from another contrib module ;)
But of course, I have no problems with Dynamic Render, or the sIFR module before that. These modules handle a small task well, they are mostly unique, and at the end of the day people choose to use what serves their purpose and works well.
What I would love to see in core is a rendering library for embedding stuff. It would provide plugins (or allow people to provide their own) for crazy stuff like SVG and Canvas. If anything like that ever happens, we have a rich field of ideas and approaches to borrow from, and no-one who contributed to the planting/watering/etc should be shamed in any way!
Thanks
Update, I looked at the
Update, I looked at the group more and I like what's going on. I think I just don't like the name :)
Thanks for this pointer,
Thanks for this pointer, sime! I've added this link to the wiki page (yes, it's a wiki page, so everyone can update it).
I started this thread after having asked in Drupal's IRC channels for a working, maintained, and future-proof Flash embedding module. No one was able to tell me the status of any of those modules.
I worked with SWFObject API before, but now need to create a Panels content-type, so (administrative) users are able to insert Flash movies as content into their panels (as pane). This means I want to contribute and improve what's there with a nice patch.
Then, I read the project page of SWFObject API, which clearly states that it is an API module only (so probably down to zero chances for getting my patch in maybe?). And it refers to swfobject module for user-facing stuff, which is completely outdated. No mentioning of SWF Tools at all.
However, knowing your efforts on SWF Tools, I looked up its status, too. Bad or good news: A new maintainer. But also, no note about related modules and why I'd want to choose SWF Tools.
Read the handbook pages about SWF Tools afterwards, which basically told me that SWF Tools provides the same SWFObject method as SWFObject API module does.
Still no clue about which module I should write a patch for. :(
Next best guess was to look at the issue queues of both modules. Usually, one of the involved modules is not maintained as well as the other(s). However, no luck here - both seem to be maintained fine.
Then I found the issue about collaboration between you guys, where one of you states
...and this is the real cause for why these duplicate efforts are bad -- not only for both modules, but also for all Drupal users. Since both of you are/were module maintainers, I don't think that I need to explain why, or what I mean in detail here.
So this is my story. I want to contribute, but I still don't know where.
Daniel F. Kudwien
unleashed mind
Daniel F. Kudwien
netzstrategen
Building Blocks
I believe the way out here would be to fix the other modules to use the API module for their engines. That takes out the code replication, and makes them all easier to maintain. Then going forward, your case would be (yes) another module, which also uses the API. I believe that developers are (sometimes slowly) learning that modules in Drupal can work together as building blocks, and this is a good analogy to explain to new users trying to understand the otherwise confusing world of contrib.
Aaron Winborn
Drupal Multimedia (book, available now!)
AaronWinborn.com (blog)
Advomatic (work)
Aaron Winborn
Drupal Multimedia (my book, available now!)
AaronWinborn.com
Advomatic
Hey sun. Thanks for the
Hey sun. Thanks for the frank response.
I think SWF Object could be ripped out of SWF Tools. (In theory there are a number of embedding methods that SWF Tools could handle, in practice there was only one most people use
Note: SWF Tools uses some jquery to walk the DOM and activate SWFObject as needed, rather than spit out activation code for every instance of an embedded object, so as long as that was available in SWFObject API ...
Ironically I wrote SWF Tools before messing with views and CCK, what a conundrum! But the structure is still sound, because the idea of SWF Tools is that you have associated file types with embedding methods - therefore a cck handler for filefield would should simple call something like:
<?php// off my head
// SWF Tools knows about default parameters for the flash tool you're embedding
// per the settings, but also allows you to override them, say if an alternative
// value was set in a field handler options.
if ($output = swf($node->somefield[0]['filething'])) {
return $output;
}
else {
return theme('however_filefield_does_it_normally', $node->somefield[0]['filething']);
}
?>
Panels and views are no-brainers then since they work with CCK handlers. But you could also just write your Panels plugin and tell if some extra parameters.
And here are the downsides of SWF Tools from when I was last in the head space:
SWFTools and SWFObject API
Sime-
The overlap between the specific SWFObject module in SWFTools and SWFObject API is really close. They both function the same way, just that their theme functions are slightly different. I do like the idea of having a consistent embedding module(s) that all contrib can make use of, though the question of broader modules verses targeted modules is one that I'm not quite sure how to weigh in on. I think it'd be good if we can get Stuart in on this conversation- I contacted him but have not heard back yet.
http://24b6.net
http://24b6.net
I doubt it would be very
I doubt it would be very hard pull out the swfobject stuff.
Just wondering how does SWFObject API handle many embeddings on a page? A lot of modules, a while back anyway, would simply repeat the same embedding javascript for each swf. But it should be done with a couple of lines of jQuery.
Multiple embeds
Actually, SWFObject API use a bit of javascript to create multiple embedded objects- theme_swfobject_api() and swfobject2_swftools_embed() are basically the same with a few exceptions. Which probably makes the argument for duplication that much more accurate :)
http://24b6.net
http://24b6.net
As my 5yo would say:
As my 5yo would say: Awesome.
Mixed feelings
While I complete agree with Sime that large modules are not necessarily better, Aaron is dead on for pointing out that the overwhelming number of choices makes contrib more difficult for people to navigate. While I'd like to hold on to having an API only module for SWFObject, I am persuaded that it makes more sense at this point to integrate with SWFTools which has a similar API function. If there is a higher adoption rate and clearer implementation, then I think integration is in order. I've contacted Stuart and proposed a compatibility layer to make the transition easy for adopters of SWFObject API. Perhaps one approach is to add maintainers for the specific aspects of these larger modules to help keep the work load down.
http://24b6.net
http://24b6.net
Flashy & SWFembed
also:
http://drupal.org/project/flashy
http://drupal.org/project/swfembed
Not sure
Flash is a specific implementation that renders content in a specific player. I think this ought to be an extension of other modules (specifically: http://drupal.org/project/embed)
Swfembed and Embed do seem to be trying to do similar things.
http://24b6.net
Aaarrrggghhh....
Guys, I am not a contributer, partly because of time constraints and partly because of the high bar one has to reach to be able to. This bar is growing higher all the time because of duplication/multiplication issues like those discussed above. I think this selfish gene approach is stifling Drupal open source development. It is still relative early days for Drupal, but the quagmire is growing ever deeper - making it harder and harder to work with - and this will eventually put people off using it or contributing to it. But you know this already.
A point that I would like to make, that I don't think has been made clearly enough above, is the module user conundrums. As a module user, I spend way too much time trying to find the right modules and trying to understanding the differences between similar/overlapping/competing ones. The commonplace lack of clear descriptive documentation - even about what the modules do - let alone how to use them - makes the task many times more complex and long-winded than it need be.
It seems to me that Drupal has become too much a free-for-all and it needs far more peer review, discipline, standards, and vision. Great open source software - like the LAMP group - are not free-for-alls. They are extremely stable, disciplined, and they evolve - forwards. This is directed evolution.
It seems to me that is it too easy to contribute to Drupal, and Drupal is getting deluged with low quality stuff and documentation - among islands of excellent work. A stringent process of peer review, with voted subject-matter-experts as chairs of focus groups needs to be put in place. It is vital that the focus groups should have technical as well as non-technical members - probably 50-50. Just not being able to contribute a module unless a peer-review group has accepted the documentation - from both a descriptive and a technical standpoint - would be a huge step forward. If such groups and processes are in place, as a relative newbie, I am not seeing much of the benefits...
GlossyIbis
Michael, with regards to
Michael, with regards to trying to select between overlapping modules, that's one of the reasons for the existence of this GDO group. If you notice there are several modules which do X and you're not sure which one will be most competent for your needs, search this group for threads about it, and failing that, start a new one. I recently did so when considering modules to provide a physical address CCK field, and the discussion was very helpful in helping me decide the approach to take.
As for requiring peer review before modules are submitted, there are two obvious problems with that idea. One is the amount of manpower it would require, and of course some "focus groups" would have more interested people or more competent people than others. The other is, of course, that quality is subjective. And it's really not too much of a tragedy for bad or incomplete code to be put up on D.o, if it's intended to be improved later; "release early, release often" is an open source software development credo.
The Boise Drupal Guy!