It looks like that&#39;s where we are headed.&nbsp; I encourage anyone interested in helping to improve TinyMCE (both the module and the Drupal specific version of TinyMCE itself) to join the TinyMCE Development group (<a href="http://groups.drupal.org/tinymce-development">
http://groups.drupal.org/tinymce-development</a>).<br><br>It was never my intention to incite such a long debate on the issue of 3rd party libraries.&nbsp; The truth is I can&#39;t do what Gerhard does from <a href="http://Drupal.org">
Drupal.org</a>, so this could have ended when he said this would be too much of an issue for the people maintaining CVS.&nbsp; IMHO the 3rd party policy is going to need to be revised for JQuery plugins, but I&#39;ve conceded that we need to find a home for at least part of TinyMCE.
<br><br>We&#39;re looking for feedback on the (next) best place to host Drupal specific development (<a href="http://groups.drupal.org/node/3364">http://groups.drupal.org/node/3364</a>) now.&nbsp; If you have suggestions, please join that group and make your suggestions there or email me directly.&nbsp; 
<br><br>I think everyone has had enough of this thread.<br><br>- Kevin Reynen<br><br><div><span class="gmail_quote">On 5/25/07, <b class="gmail_sendername">Andrew ft</b> &lt;<a href="mailto:andrewft@gmail.com">andrewft@gmail.com
</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div>Here is a practical interim suggestion:</div>
<div>&nbsp;</div>
<div>-Split the TinyMCE module into two parts:</div>
<div>&nbsp;1. a Drupal module</div>
<div>&nbsp;2.&nbsp;a second&nbsp;module which is just a container for&nbsp;the TinyMCE libraries patched for Drupal and ready to go.</div>
<div>-Host the first module on <a href="http://Drupal.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">Drupal.org</a> and the second externally</div>
<div>-Make the first module dependent on the second with clear instructions about where to get it from.</div>
<div>&nbsp;</div>
<div>That way TinyMCE will still show up on the statistics as one of the most downloaded modules (which was one of the main reasons for not hosting the whole thing offsite), but we avoid all the arguments about hosting foreign code in the CVS.
</div>
<div>&nbsp;</div>
<div>I firmly believe that in the case of TinyMCE an exception should be made to allow the modified library into CVS, but this might be a step towards that goal without upsetting anyone.<br><br>&nbsp;</div><div><span class="e" id="q_112c4f55928d87fb_1">

<div><span class="gmail_quote">On 5/25/07, <b class="gmail_sendername">Tao Starbow</b> &lt;<a href="mailto:starbow@citris-uc.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">starbow@citris-uc.org
</a>&gt; wrote:</span>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0px 0px 0px 0.8ex; padding-left: 1ex;"><br>&gt; As I see it, the commit of 3rd party libraries in Contrib generally should not be allowed as:-
<br>
&gt;<br>&gt; a) It basically creates a duplicate code repository of code that should be availble from a single authoritive source.<br>&gt;<br>Or you can see it as creating a tested version known to work with a<br>given version of a drupal module.&nbsp;&nbsp;This is the entire idea behind
<br>versioning!&nbsp;&nbsp;Otherwise, if I create a drupal module that interfaces with<br>a 3rd party code base, I need to: chase after their development; see if<br>their latest version breaks my drupal wrapper; put info into the README
<br>like &quot;only works with version 1.3.1&quot; (which will be ignored by many<br>admins); and then somehow deal with the possibility that the 3rd party<br>might stop offering version 1.3.1 for download.<br>&gt; b) Uses 
Drupal.Org resources to effectively host &quot;someone elses work&quot;.<br>&gt;<br>Or you can see it as using <a href="http://drupal.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">drupal.org
</a> resources to make things much<br>easier for drupal administrators.<br>
&gt; c) It&#39;s potentially a security risk, especially if maintainership is slack. Although problems aren&#39;t Drupal related directly it presents a sloppy view of the project as a whole imho.<br>&gt;<br>I am still not understanding this argument.&nbsp;&nbsp;Right now I can create a
<br>Hackme module that, say, emails your database password to all of your<br>users on instillation. I can upload this module as a project to<br><a href="http://Drupal.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
Drupal.org</a> and have it hosted by drupal cvs.&nbsp;&nbsp;I, or any of the hundreds
<br>of other unaudited developers, can accidentally create modules that open<br>up your site to cross site scripting.&nbsp;&nbsp;The security risk of the current<br>setup is pretty much infinite.&nbsp;&nbsp;How does allowing 3rd party code<br>

increase it?&nbsp;&nbsp;And how does making someone download that 3rd party code<br>from a different source decrease it?<br></blockquote></div><br>
</span></div></blockquote></div><br>