Re: Drupal's CVS policies... including 'foriegn' codein TinyMCE module?

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/trun
k/wp-includes/js/jquery/interface.js
>> http://trac.bbpress.org/browser/trunk/bb
-includes/js/jquery/interface.js 
>> <http://trac.bbpress.org/browser/trun
k/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-include
s/js/tinymce 
>> <http://trac.wordpress.org/browser/trunk/wp-inc
ludes/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* <starbowcitris-uc.org 
>> <mailto:starbowcitris-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.
seanrngpsoftware.com
(202) 686-9330
http://www.ngpsoftware.com

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-include
s/js/jquery/ 
>>> interface.js
>>> http://trac.bbpress.org/browser/trunk/bb-includes/js
/jquery/ 
>>> interface.js <ht
tp://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-include
s/js/tinymce  
>>> <http://trac.wordpress.org/browser/trunk/wp-inc
ludes/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* <starbowcitris-uc.org  
>>> <mailto:starbowcitris-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.
> seanrngpsoftware.com
> (202) 686-9330
> http://www.ngpsoftware.com

>