I had conceded to host the Drupal specific version of TinyMCE myself, but Tao's message was interesting enough to suck me back in to this. <br><br>Round 2... ding, ding<br><br>Nedjo asked about the 3rd party library issue (
<a href="http://drupal.org/node/124978">http://drupal.org/node/124978</a>), but it looks like Jeff just went ahead and uploaded the files he wanted to use to CVS as part of the modules instead including links and documentation for where to download the files and how to install or configure them.
<br><br>Jeff includes unmodified? versions of jquery.js 1.1.2 and compat.1.0.js (<a href="http://dev.jquery.com/browser/trunk/plugins/compat-1.0">http://dev.jquery.com/browser/trunk/plugins/compat-1.0</a>) in jQuery_update. The
interface.js (78k) included in the JQuery_interface is available from the developer at <a href="http://interface.eyecon.ro/changelog">http://interface.eyecon.ro/changelog</a><br><br>I also found it here...<br><br><a href="http://trac.wordpress.org/browser/trunk/wp-includes/js/jquery/interface.js">
</a><br><br>Ironically, you can also find the WordPress optimized version of TinyMCE in wp-includes as well...<br><br><a href="http://trac.wordpress.org/browser/trunk/wp-includes/js/tinymce">http://trac.wordpress.org/browser/trunk/wp-includes/js/tinymce
</a><br><br>TinyMCE IS included as part of the WordPress "core", but as a customized/optimized/compressed version with a small number of plugins (<a href="http://trac.wordpress.org/browser/trunk/wp-includes/js/tinymce/plugins">
http://trac.wordpress.org/browser/trunk/wp-includes/js/tinymce/plugins</a>). By dropping the <br>_src.js files and unused themes/icons, the WordPress TinyMCE is a much smaller download. They also include WordPress specific plug-ins for functionality and help. These are the types of optimizations I'd like to be doing to TinyMCE for Drupal, but the current CVS policy requires me to host a Drupal specific version of TinyMCE myself.
<br><br>For the TinyMCE module, it doesn't make a whole lot of sense to put the required library in another download since the module's sole purpose is to enable and configure the TinyMCE library, but if other modules requiring external libraries standardized on how the libraries are handled I'd go along for that ride. Assuming there are no licensing conflicts, libraries could be treated as modules. Library dependencies could be handled by the .info, someone would have 'own' the security and support issues related to the library just like maintainers (in theory) own these for modules, and version conflicts between developers using a common resources could be worked out the same way they are now.
<br><br>I don't know what the ramifications of this suggestion would be for the people maintaining the CVS, but there are obviously active developers who are frustrated by the policy and others who are just ignoring it.
<br><br>- Kevin Reynen<br><br><br><div><span class="gmail_quote">On 5/24/07, <b class="gmail_sendername">Tao Starbow</b> <<a href="mailto:firstname.lastname@example.org">email@example.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>> aps to address this concern, we could create a dedicated module that<br>> simply provides the third party library in question and little or no<br>> additional functionality as required by drupal. The the modules that
<br>> depend on it can do just that in the info files. Avoids duplication<br>> and centralizes the management and ability to audit for security<br>> issues too boot.<br><br>This is the approach Jeff Robins has taken with his jQuery_update and
<br>jQuery_interface modules, and I think it works very well. This approach<br>leverages Drupal's project versioning and dependency systems to keep the<br>3rd party (GPL) code insync with the Drupal code, and simplifies