Visit the forum instructions to learn how to post to the forum, enable email notifications, subscribe to a category to receive emails when there are new discussions (like a mailing list), bookmark discussions and to see other tips to get the most out of our forum!
  • In recent months, the production of OSE documentation has seen a strong
    up-tick.  Besides the work I'm doing on the steam engine project, Marcin
    has been working on describing the CEB Liberator, LifeTrac, and
    PowerCube fabrication processes. Recently, a page was created at
    http://opensourceecology.org/wiki/Documentation_Standards to address
    this issue (though it doesn't say much).  It does mention the use of an
    FTP repository as the place to store documents.



    I've recently come up against the "where does this stuff live" problem
    as well.  I'm creating FreeCAD documents for the steam engine parts and
    the OSE wiki doesn't recognize them as a valid file that can be posted. 
    I tried ZIPing them as well, but zips are not supported either (which
    is silly).



    To my mind, a document repository system falls directly into the
    collaboration task you've been working on.  Personally, I think FTP is a
    bit crude for our needs.  I'd rather use something like Drupal which
    has support for document versions, history, and a better web interface
    than FTP.  My understanding is that Google Projects have been used in
    the past as well, which I'm fine with.



    What are your thoughts on this?

    - Mark

     
  • 12 Comments sorted by
  • 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"




     
  • BTW, you can create usually smaller archives than ZIP by using tar with gzip or bzip2 (tgz, tbz extensions), or even smaller ones by using the LZMA2 algorithm provided by 7-zip or XZ Utils, so that could be another reason to avoid ZIP files.

    P.S.: I've updated the list to allow '7z' and 'xz' file extensions.
     
  • 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).

     
  • Elifarley, Good to know tar.gz is supported.
     
  • 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

     
  • I think Eerik's idea of using Spip is interesting.

    Eerik, can you elaborate a bit about how we could use Spip as a document repository?
    Do you have examples of sites using it as such?
    Can you provide a working example under http://eerik.opensourceecology.org/ ?

     
  • 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 tried it.  Didn't work.

     
  • 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?
     
  • I got the email, at least.  Eerik said:

    ... It seems the server no longer points at the folder Spip is in.
    It seems Elifarley may have used it to test the wiki then pointed it back to the wrong place.

    as http://eerik.openfarmtech.org/ now arrives at a folder where I had put a test page on.

    - Mark
     
  • this SPIP conversation just won't die!

    just so everyone knows, to the extent that marcin has chosen me to develop this platform, i'm not going to use SPIP for anything. it has an awful architecture: its controller is convention based on files referencing each other via a sequence of *numbers*, and then there's an entirely *separate* set of files to handle POST requests. compare this controlling mechanism to just about anything else (MVC or event driven web frameworks, or CMSes like drupal or wordpress), and you'll see its controller architecture alone is asinine. strike one.

    and yes, its markup language is in French.   strike two.

    and unlike drupal, wordpress, rails, zend, python, or numerous other frameworks that do things in standard ways, SPIP is all but unknown among the large community of web developers in the English speaking world -- and for good reason -- it's not worth knowing about. strike three: no one knows it. 

    Only Eerik advocates its use, and he's never used anything else and admits he's not a web developer. he repeatedly trumpets its "advantages", when in fact, every other framework has at least the functionality he talks about, and none of the disadvantages. so he simply has no basis to make comparisons. strike four! 

    he's also never worked with other developers: strike five. 

    and he's prefers to rebuild every wheel from the ground up since he's unfamiliar with leveraging other technologies. strike six.

    now, if you're not a web developer, you're not really qualified to evaluate what tech we use, or who we choose as a developer. if you are, and none of the strikes above sway you, well: you should know better! 

    and Eerik, you're here because you're a stakeholder and came up with the blogosphere idea; you're not here in your capacity as an SPIP advocate. if you keep distracting us with SPIP, i'm taking you off of the collab platform team (this forum and pivotal). yes this is open source, but open source projects have leaders, and Marcin chose me, and believe me, i'm starting to regret it. but the core team has to communicate, and we're not communicating. we went around on this for weeks on emails already, and enough is enough!

    just about any other well known CMS or web framework, that uses a standard architecture, is in English, and is open source, would be far preferable to SPIP, and i would doubtfully object to it. i'm not religious about frameworks or language, but SPIP is just an awful choice.

    i'm going to put the call out for some  agile, open source, web developers to help us choose something suitable. i don't want to dictate what we end up using, but SPIP is most assuredly not it.

    -vann
     
  • Mark, we do need to choose some kind of repository. Marcin spoke to me about the need for this today; I had previously been under the impression that he was happy with Open Pario; this is not true. He's got a couple people he's putting me into contact with; I'll keep you in the loop.
     

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Login with Facebook Sign In with Google Sign In with OpenID Sign In with Twitter

In this Discussion

Tagged

Loading