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

[Matthew Farina]

Can someone explain what would be the difference between including a  
configured TinyMCE and TinyMCE from moxiecode?  Would it just be the  
configuration file or more?

I'm starting to wonder if going with a ftp/sftp approach (like  
Joomla) has wouldn't be a bad idea.  We could keep the code out or  
our repository yet have the installer pull it down and put it in the  
right place/give a simple upload window as a step with instructions  
where to download it.

In the case of TinyMCE, if it's just the config file that could be  
written via this ftp/sftp functionality.

And, maybe not allowing the change to CVS policy would give incentive  
to write the ftp functionality.

Just some thoughts....

Matt

On May 24, 2007, at 6:31 PM, Sean Robertson wrote:

> I would like to see a Drupal-optimized TinyMCE package.  It'd make  
> it a lot easier on me if it had standard Drupal-related plugins  
> already installed so I didn't have to do that manually for every site.
>
>
>
> Matthew Farina wrote:
>> At this point a number of merits for both directions have come out  
>> here.  Currently the policy is to not have them in CVS.  What  
>> would it take to change that policy?
>> On May 24, 2007, at 3:04 PM, Kevin Reynen wrote:
>>> 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 <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  
>>> <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  
>>> <mailto: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.
>>>
>>>
>
> -- 
> Sean Robertson
> Web Developer
> NGP Software, Inc.
> seanr at ngpsoftware.com
> (202) 686-9330
> http://www.ngpsoftware.com
>