URL='http://10.0.0.1' MIME='image/jpeg' 
  bash -c 'wget -q -O - "$URL/wiki/index.php?title=Special:MIMESearch&mime=$MIME&limit=500&offset=0" 
  | grep -Po "/wiki/images[^"]+" 
  | xargs -n1 -I {} wget "$URL{}"'

What it does: it uses the “MIME search” functionality on the wiki to locate files of a certain mime type and then xargs+wget each of them.

Limitations:

• A maximum of 500 files are downloaded
• Downloads are not parallelized, thus slower than they could be

• Easier to write. This means both speed (because I already spend quite a lot of time with different side-projects) and less formatting-cruft to add (so that I can concentrate on the actual content)
• Offer useful features to the readers (like syntax highlighting and line numbering for source code)
• Make the markup clean and semantic

Naturally I was interested when the Is HTML a Humane Markup Language? showed up in my feed reader, followed by Markdown, Oh the Humanity. However I find myself on the opposing side of the fence, agreeing with the points from the original Why Doesnt Wiki Do Html post. The most important rule is (and I’m paraphrasing here):

Blogs emphasis is on content, not presentation. Simple markup rules make people focus on expressing their ideas, not making them pretty.

Two main griefs I have with HTML as a markup language are:

• It needs a lot of typing. Just for this list I had to type:
  

  <ul>
    <li></li>
    <li></li>
  </ul>
  

  
  This is both inefficient, and makes you get out of the zone and slowing you down. Remember, we can’t multitask, just switch quickly between different tasks and the less we need to do that, the more efficient we are (and mind you, I’ve been using HTML since the days of Netscape 2.0, so it’s not that I’m not familiar with it)

• Sometimes a lot of code is needed to express concepts like syntax highlighted code. This code (generated automatically) does not lend itself to automatic transformations (for example what if I decide that I want to add/remove line numbering to all of my code samples?)

Currently I see two possible solutions to the problem:

Use a WYSIWYG editor. The problem with these are that they tend to produce horrendous markup, although lately they started to improve. Currently I’m toying around with Windows Live Writer but I don’t like certain aspects of it and I’m thinking about writing some plugins to make it behave the way I want to – if only I could make it run with Mono… Its main advantage is that, as a native (as opposed to web) application it can nicely interface with the filesystem and make things like uploading images easi(er).

As any problem in computer science, things can be solved by introducing an other layer of abstraction :-). That is some kind of markup language which codifies the concepts important to the user. This solves the problem of brevity (usually) and also makes it simple to change the styling (simply replace/tweak the code which translates it into HTML). The syntax offered by DokuWiki is quite good (although it has some inconsistencies), the MediaWiki syntax seems to cobbled together, a mix of pseudo-HTML and custom tags, and don’t even get me started about their table syntax :-|. But in general the approach is workable.

Finally, some words about WYSIWYG editors for wikis: they are really useful for initial adoption, but the usual approach to retrofit a full editor like TinyMCE suffers from the problem of not being extensible (this is especially important for software like DokuWiki where there are a lot of extensions which produce their own custom tags). One interesting approach which I found in the comments was the markItUp! editor. Aside from being based on my favorite JS library (jQuery), it has the advantage that it tries to speed up editing of the markup language, rather than trying to perform the complete HTML -> markup and back conversion. The approach is similar to the one employed by the XStandard editor (which I heard of via the excellent Boagworld podcast), whereby, rather than giving people the possibility to control directly the style of the text, they rather mark the type of content it represents, and the style sheet controls the actual way it is displayed.

• It is open source (just click the for developers link)
• It is free (if you don’t want the support)
• It is written in Perl
• It has an API for manipulating the pages (I don’t know yet how powerful it is)
• It has a WYSIWYG editor
• Commets can be attached to every page
• It integrates with Active Directory

What I don’t like (these are my first perceptions while browsing around the site, I didn’t have time yet to install it and do an extensive testing):

• The access control seems to be a little limited (like admin / non-admin), I would have preferred something more along the lines of Active Directory or at least the Unix model with groups and group members
• It doesn’t seem to support code blocks. I thing one of the major features of DokuWiki is the integration with GeSHi for syntax highlighting of source code.

I’ve heard about it over at Perlcast