Mark,

MediaWiki uses $wgFileExtensions to control which file extensions are allowed (see http://www.mediawiki.org/wiki/Manual:$wgFileExtensions)

I have added the file extension you requested, and now our list of allowed file extensions is:

$wgFileExtensions = array( 'png', 'gif', 'jpg', 'jpeg', 'ppt', 'pdf', 'doc', 'psd', 'mp3','xls', 'swf', 'doc', 'odt', 'odc', 'odp', 'ods', 'odg', 'xls', 'mpp', 'svg', 'dxf', 'blend', 'FCStd', 'dia', 'bz2', 'gz', 'tbz', 'tgz');

ZIP files are not allowed because they pose a security risk, according to http://www.mediawiki.org/wiki/Manual:$wgMimeTypeBlacklist . On that page, you'll see this:

"A ZIP file may be a valid Java archive containing an applet which exploits the same-origin policy to steal cookies"

Hey Mark, yes, I'm not as long on this as you, but I also don't know where all documents should go.

Also, in the documentation standards, there's the request for all drafts etc. used to make final products. For instance the images used to make the GIF animations I made are PNG, themselves based on moving/hiding layers in GIMP.

It would be good to have all that material out there.

I initially proposed FTP for transferring large amounts of HD. But I think FTP could also be good at is storing our "work space" as project leaders (people that join the team could then rsync the whole workspace).

I can work with tarballs, no problem.  However, there is the larger question of the document repository.  Are we going with  FTP?  Drupal?  Git?  Something else?

- Mark

Elifarley asked me to weigh in with how this question would be resolved with Spip.

Basically, like any CMS you'd be able to upload files/images and embed them in pages, an icon then shows up (that we could change if we wanted) and people can click on the icon (or you can hard link from elsewhere).

For updating files, the original file can be "switched", or simply a new file uploaded, depending on if you want people hitting the old link (that may by now be all over the internet) arriving on the old or new file. (or the original file can be switched for an identical one except for the warning "this file is outdated and is here for historical purposes, new files is located at...")

Also, in Spip there an upload FTP folder, where you can upload via RSYNC/SSH/FTP all the files you want and mass import them into import them into Spip at the same time. Once in Spip every uploaded file is assigned a number in chronological order and you then call the object by a tag. This is fairly convenient for either large files or a large amount of files.

One big convenience of Spip is that photos can be uploaded up to 8 Gb and Spip can resize all the photos to a standard dimension (but the original can be either accessed via clicking on the image). The "standard dimension" can be changed for each section or each article, i.e. a technical section may have a larger standard image size than a section housing updates. This is fairly convenient since the tag of a technical image can be dropped in multiple sections and is then automatically dimensioned to the standard of each section. So, basically there is no redimensioning images by hand at all (unless you want smaller than the standards, in which case by default Spip will not resize upwards). Naturally, every dimension a image appears as is cached.

For whatever platform is chosen, this automatic resizing I think would be a good feature for OSE which is fairly image oriented.
Also, title description, etc. can be added to the image which we can make appear underneath or on rollover or whatever, globally or depending on the section it is in.

Also, Spip is oriented folder wise, just as it anyones computer, so back-office you're presented with a bunch of folders and sub-folders, and (if you have admin rights to a folder) you can make infinite sub-folders. The webmasters then take care of having the articles in every folder automatically appear where they're supposed to. If setup correctly all the contributors do navigate to the relevant folder, create and article and hit save.

All this functionality could of course be either programed in another framework or may be available in a CMS. Though I think it would be particularly easy in Spip, this may be a matter of opinion.

For those interested, the documentation is http://programmer.spip.org/IMG/pdf/documentation_en.pdf .
I also set up a small example at http://eerik.opensourceecology.org/
You can create an account at http://eerik.opensourceecology.org/ecrire
(you must click register at the bottom and but your email address in, then it emails you access and automatically creates a folder you can publish in)
All the details can be changed; also for now there is no lblogs template setup so publishing won't really appear publically, it's just to
 give a basic idea of the system.

I've gone to http://eerik.opensourceecology.org/ecrire
and clicked on "register", then I entered my name and my email, and submited the form. this brought up this message:

"Your new identifier has just been sent to you by e-mail."

After about 2 minutes, no email has arrived at my inbox.

Maybe there's a problem on the mail server. Is it Exim?

this SPIP conversation just won't die!