Instiki
TODO

This is a TODO list of improvements I’d like to see in this branch of Instiki. You might also want to look at the Known Bugs page. They need work, too.

If you’re interested in working on any of these topics, set yourself up with BZR, do a

% bzr pull http://golem.ph.utexas.edu/~distler/code/instiki/svn/

and start hacking away. Send me an email, when you’ve gotten somewhere, and I’ll pull the changes from your BZR repository.

Rails 3

Rails 3 was released a year ago. There are a lot of changes in Rails 3, so it’s a nontrivial task to port Instiki to it.

Themes

On the other hand, implementing Themes-support looks quite easy for a Rails3 application. That would be a very nice payoff for a Rails3 Port.

Discussions

Rails 3.1 is nearing completion. Among its many cool features is revamped support for engines. Previously, that seemed pretty awkward. But now, embedding Heterotic Beast in Instiki, and getting real discussion pages seems quite doable.

TeX Output

1. There are a few remaining LaTeX macros which would need to be defined to support the various itex commands that are not part of standard LaTeX. See the the preamble in the LaTeX template, app/views/wiki/tex.rhtml.

2. The LaTeX export is a (Markdown+itex)→LaTeX conversion. It does not know anything about Wiki syntax. Changing this would be a nontrivial task.

Maruku

Maruku:

1. is GPL2-licensed, which conflicts with the license of the rest of Instiki. Swapping it out for another Markdown interpreter is a trivial matter of changing a couple of lines of code. Finding an interpreter for the rich superset of Markdown, that Maruku supports, would be nontrivial.
2. is slow. A C-based alternative, like rdiscount or rpeg-markdown would be much faster.

Point (2) is partially alleviated in my Nokogiri branch of Maruku, which speeds up the #to_html serialization by a factor of 4–5 (REXML does, indeed, suck), which yields a factor of 2–3 in the overall Markdown processing-time. But we ought to be able to do much better.

Of the alternatives, rpeg-markdown sounds more promising. It’s a wrapper around peg-markdown, which relies on a PEG-grammar to define the Markdown that it parses. So, a-priori, we “just” need to define a PEG-grammar for the Markdown superset we are interested in.

Sanitizer

The Instiki Sanitizer is very thorough but it, too, is no speed-champ. Borrowing the tokenizer from libxml2 (say) would speed it up a lot.

Access & Authentication

Currently, Instiki’s access controls are quite primitive. It uses plaintext passwords to protect entire Webs. It doesn’t have any notion of “users”, nor any sort of more fine-grained access-control that might be afforded to authenticated users.

Of course, you can always use Passenger or proxy Instiki through Apache. Then you could avail yourself of Apache’s authentication and access-controls. But that’s not nearly so user-friendly.

Perhaps some combination of restful_authentication and openid_authentication might be helpful (though I prefer digest authentication to using passwords).