[development] Drupal's CVS policies... including 'foriegn' code in TinyMCE module?

[Kevin Reynen]

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.

Round 2... ding, ding

Nedjo asked about the 3rd party library issue (http://drupal.org/node/124978),
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.

Jeff includes unmodified? versions of jquery.js 1.1.2 and compat.1.0.js (
http://dev.jquery.com/browser/trunk/plugins/compat-1.0) in jQuery_update.
The interface.js (78k) included in the JQuery_interface is available from
the developer at http://interface.eyecon.ro/changelog

I also found it here...

http://trac.wordpress.org/browser/trunk/wp-includes/js/jquery/interface.js
http://trac.bbpress.org/browser/trunk/bb-includes/js/jquery/interface.js

Ironically, you can also find the WordPress optimized version of TinyMCE in
wp-includes as well...

http://trac.wordpress.org/browser/trunk/wp-includes/js/tinymce

TinyMCE IS included as part of the WordPress "core", but as a
customized/optimized/compressed version with a small number of plugins  (
http://trac.wordpress.org/browser/trunk/wp-includes/js/tinymce/plugins).  By
dropping  the
_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.

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.

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.

- Kevin Reynen


On 5/24/07, Tao Starbow <starbow at citris-uc.org> wrote:
>
>
> > aps to address this concern, we could create a dedicated module that
> > simply provides the third party library in question and little or no
> > additional functionality as required by drupal. The the modules that
> > depend on it can do just that in the info files. Avoids duplication
> > and centralizes the management and ability to audit for security
> > issues too boot.
>
> This is the approach Jeff Robins has taken with his jQuery_update and
> jQuery_interface modules, and I think it works very well.  This approach
> leverages Drupal's project versioning and dependency systems to keep the
> 3rd party (GPL) code insync with the Drupal code, and simplifies
> instillation.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20070524/9fb15b9c/attachment.htm