Hi Bobby, Thank you for positive feedback and also for bringing these legal concerns to my attention generously.
The legal concerns and authors. I've updated all of the plugin JS files to include the proper legal nods, and I took an extra precautionary measure of adding jQuery's licenseing to the mix as well. I've been using SWFObject in the SWFObject edition of the jQuery sIFR Plugin @ http://jquery.thewikies.com/swfobjectsifr/ and will add the copyrights there as well. I would like to state that I *found* the "author" by SWFObject googling my way over to deconcept and then clicking the "About" link; contrary to the rumors that I'm a Vatican 1 Geoffolic. The phrasing. Yes yes yes , I read it again, and then again with a palm to my face. I wrote it on the fly, and in an attempt to sound exciting I think my descriptions were zealous and kinda jerkish (sorry). It's been updated to hopefully better reflect the benefits to the user while keeping an excited and homebrew tone. Your corrections and suggestions really helped and I predict that I'll be rewriting that one a few times over. YUI Compressor. Amazing. Thank you. Later tonight I'll have more time to start updating all of my script to take advantage of this. The most difficult task ahead of me technically is to now fully break apart SWFObject and best leverage jQuery's built-in functionality, while maintaining a reasonable delta between SWFObject and it's jQuery counterpart. Two looming questions. I have a sandbox @ http://jquery.thewikies.com/swfobject/sandbox/ where I've been twisting and torturing certain features of SWFObject to determine the best course of action. I noticed that SWFObject attaches objects to the DOM versus generating a string to inject via inner or outer HTML. Is there a performance reason for this? How do any community members and certainly SWFObject authors here feel about me adding functionality to the jQuery port that allows users to generate and return the flash embedding without forcibly attaching it to the DOM, e.g: returning the virtual elements to be used later. Maybe SWFObject already does this? Does what I'm suggesting make sense? On Oct 14, 2:20 am, Bobby <[EMAIL PROTECTED]> wrote: > Hi Jonathan, > > Great work,we're happy to see that you've picked up SWFObject and > created a jQuery plugin :-) > > While browsing through your project and documentation there are a few > things that I noticed, and while it is a big list, please regard it as > positive feedback to improve your project. > > First and most important. Although probably unconsciously, you are > currently violating our copyright. SWFObject 2 use the MIT license > [http://www.opensource.org/licenses/mit-license.php], which clearly > states: "Copyright (c) <year> <copyright holders>" and "The above > copyright notice and this permission notice shall be included in all > copies or substantial portions of the Software." > > This means both your minified and uncompressed versions of jQuery > SWFObject need to include the exact following copright header: > /* > SWFObject v2.1 <http://code.google.com/p/swfobject/> > Copyright (c) 2007-2008 Geoff Stearns, Michael Williams, and Bobby van > der Sluis > This software is released under the MIT License > <http://www.opensource.org/licenses/mit-license.php> > */ > > The SWFObject version number will tell your users which version of > SWFObject your derived software maps to. We do take copyright > infringements very seriously, so please update this as soon as > possible. > > Regarding your documentation, it's currently incorrect and rather > misleading: > > > What's difference between this plugin and regular SWFObject? > > First, it's smaller. Where SWFObject needs to create its own > > selectors / DOM loaders / and the like, that functionality has been > > removed and replaced with jQuery's pre-existing ones. > > For existing jQuery users it is smaller. It's the opposite for non- > jQuery users. Now, looking at execution, currently your minified > version of jQuery SWFObject plugin is 10.9K (without the required > copyright header), while SWFObject only is 9.7K. Now, you should be > able to create a smaller version using a better compression tool, so > you might want to check that out. Please also > read:http://code.google.com/p/swfobject/wiki/how_to_compress > > > Then, it's > > faster. There's little argument that jQuery's functionality is about > > as fast as complaint javascript can get, so now you get these same > > performance benefits in SWFObject. > > Incorrect. SWFObject's DomContentLoaded or document.getElementById > will just fire as fast jQuery's (the main way to get references in > SWFObject). > > I think that you are mixing up different things here. From what I've > read John Resig has gone through great lengths to improve jQuery's own > performance and has done some benchmarks regarding selectors, however > as explained above SWFObject primarily uses direct references, so no > speed optimizations will be possible here. Also, you can only make > statements like this if you can quantify them, e.g. with an objective > benchmark (if they exist). So this line is misleading and should be > omitted. > > > Finally, it's easier. Code looks > > cleaner with jQuery, and it's almost always easier to read and get > > what's going on. Having the power of SWFObject and the environment of > > jQuery is a best-of-both-worlds scenario. > > Again, this only counts for existing jQuery users. > > To summarize the benefits of jQuery SWFObject over SWFObject: > - For existing jQuery users it can offer a file size improvement if > done correctly (and I am positive you will get there) > - For existing jQuery users it uses the jQuery style of authoring > > The downside of jQuery SWFObject over SWFObject: > - Not officially supported by the SWFObject team and functionality may > differ from the original (I speak from experience, e.g. the old UFO > jQuery plugin suffered from incompatibilities). This means that it is > up to the author and jQuery community to test, update and maintain the > plug-in. > - Not interesting for non-jQuery users > > Another thing I would like to see changed is that on your project's > website you currently only name 1 SWFObject author, while there are 3 > authors, so please update this. > > Again, this is all positive feedback to improve your project, which by > itself is great work, however still work in progress. You do need to > add the copyright header to all your jQuery SWFObject files. The rest > I leave up to your discretion. Please let us know when updates are > made. Furthernmore, if we think the updated information on your > project is correct, we are happy to add a link to it in the near > future. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "SWFObject" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/swfobject?hl=en -~----------~----~----~----~------~----~------~--~---
