I think this was supposed to go here... ---------- Forwarded Message ---------- Subject: Re: [development] Drupal's CVS policies... including 'foriegn' codein TinyMCE module? Date: Monday 21 May 2007 From: "Kevin Reynen" <kreynen@gmail.com> To: larry@garfieldtech.com I thought about that, but how would the module know the path to the current version of TinyMCE Moxiecode has released... or if that's compatible with the module version/Drupal version/ theme? I could maintain a pointer to that path somewhere building in an additional dependency and potential security risk. Instead of inserting suspect code into Drupal's CVS... hijack the location gettinmymce.php returns and install any code you'd like? Have you looked at the install/maintainence process SMF uses (http://www.simplemachines.org/). It's really slick, but it only pulls from their CVS/SVN? which I think is the only way to make that type of install secure. I think the Update Status module (http://drupal.org/project/update_status) should eventually incorporate SMF-like installs, but since Nedjo Rogers maintains Update Status AND contributes to TinyMCE... my guess is if there was a secure, reliable way to install Moxie's latest release that way or update Drupal modules from the CVS, he'd already be doing it. - Kevin On 5/21/07, Larry Garfield <larry@garfieldtech.com> wrote:

Is this something that could be handled technologically? The balloon-CVS

argument for foreign code is valid, IMO, but so is modules that rely on foreign code being too hard to install currently.

I know we can't install extra code via the UI for security reasons, but

would it be possible to include a small shell PHP script with the TinyMCE module that would download the latest TinyMCE from moxie, untar it, and put it where it belongs? The install hook for the module could then have a drupal_set_message() "Module installed, please remember to run gettinmymce.php from the command line" or something like that. It's similar to the way some Linux distros handle non-free media codecs. Something that wouldn't require reading the README file to figure out.

Possible? Reasonable? (Two separate questions. <g>)

--Larry Garfield

On Mon, 21 May 2007 14:38:58 -0400, Andre Molnar <mcsparkerton@yahoo.co.uk>

wrote:

...

Kevin Reynen wrote: <snip>

I think the issue has little to do with hatred of WYSIWYG. As I understand it, the problem is that it would set a bad precedent for CVS usage.

Lets take the case of module foo that is simple small lightweight interface between Drupal and some massive external library. With the current rules module foo is only 10K in CVS. If module foo included the external library as well - foo suddenly grows to 300K.

But foo is really important to people - and people really like foo and people complain about foo's install process (having to separately download the external library). So an exception is made for foo...

Then along comes module bar - just as important and just as popular and another exception is made.... then along comes module baz.

Baz may or may not be important or well loved - but the maintainer says "Why you picking on module baz when foo and bar get to include their external libraries?"

--- Solution? On the project page you can always include a link to a fully packaged TinyMCE module hosted elsewhere. The only thing is that you would have to maintain your own packaging.

andre (a person who would love to have tinymce pre-packaged but understands completely why it shouldn't be that way)

------------------------------------------------------- -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson