Some people seem to have missed this point... I want to CHANGE the configuration of TinyMCE from Moxiecode's default configuration to eliminate the double filter issues for Drupal users. I can legally do that because the libraries are licensed under LGPL. I can also legally distribute the customized TinyMCE with open source (or even commercial) software. There are several CMS and blogging packages that distribute customized versions of TinyMCE instead of asking their users to make the configuration changes and then dealing with the support issues that creates. IMHO, this is a much better solution for the everyone involved, but if 3rd party libraries are never going to be rolled into Drupal releases through CVS or some other method, what do you suggest? 1) Distribute single step "official release" of TinyMCE outside of Drupal and don't worry about any download lists or the precedent having a popular module distributed outside of Drupal sets 2) Leave the multi-step install/configuration in place and spend my time answering the same questions over and over instead of developing new features... or just tell those users to RTFM and leave those questions unanswered 3) Set up my own CVS/SVN to distribute the Drupal customized version of TinyMCE and either build an autoinstall for external libraries into TinyMCE or hope someone adds that to a module like Update Status None of these seem like ideal solutions, but I'm leaning towards #1. I'd rather spend the free time I have this summer developing new Drupal specific TinyMCE buttons to make publishing rich media easier for my users (and making people aware of the other user contributed buttons available for YouTube, PHP editor, unicode keyboard, etc) than answering the same support questions or developing an auto-install process. If the CVS policies are changed or a way to easily incorporate 3rd party libraries is developed, I'll be glad to move the "official release" back to Drupal.org. - Kevin Reynen On 5/22/07, Jakob Petsovits <jpetso@gmx.at> wrote:
On Tuesday, 22. May 2007, Lodewijk Evers wrote:
Why not to add it to the drupal CVS repository: If the FCKeditor were uploaded into CVS that would mean that there would be ~500 extra files in the repository, which just isn't clean and proper. CVS is for tracking development, and since no-one in their right mind will be developing for the FCKeditor or tinyMCE project in the drupal repository (that would be a fork of those projects) it does not make sense to include those files in there either. Those 500 files will just be doing nothing there and taking up resources like a fax modem in a centrino laptop. A guideline could be that if a project has a repository of their own, and even a complete developer community - don't even think about importing it into the drupal repository.
I completely agree here.
A possible solution to that problem could be one or more description files which cause drupal.org to download a file when a project release is created, and optionally unpack it in the folder where the description file lies. You get the idea:
/tinymce.fetch: url = http://ovh.dl.sourceforge.net/sourceforge/tinymce/tinymce_2_1_1_1.tgz description = "TinyMCE source package" archive = tgz
When the release is created, the url is downloaded, extracted with tar into the module's root folder, and the tarball's contents (the tinymce/ folder) are packaged together with the module.
This does not solve the security issue (assuming that this really matters) and does not solve license incompatibility issues (which can still be tracked though, by inspecting release tarballs of modules containing .fetch files or downloading the url manually), but it does solve the code duplication problem.
It's not up to me to decide if the remaining problems are big enough to keep up the restriction.
Cheers, Jakob