Instiki
TODO (changes)

Showing changes from revision #50 to #51: Added | Removed | Changed

This is a TODO list of improvements I’d like to see in this branch of Instiki.

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.

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 “TeX” link at the bottom of each individual page works. But the “export entire web to TeX” function is busted. This should be fixed or removed. (I’ve disabled it, along with the pdf-output feature. Neither really worked right, and both are dog-slow.)

Textile

RedCloth should really be replaced by a Textile input parser for Maruku. This is roughed-in, but needs to be implemented.

Maruku would be faster than the regexp-based RedCloth. But, more importantly, this would make it safe to send Textile content as application/xhtml+xml. Right now, using the Textile filter is strongly discouraged.

Content Negotiation

1. Failing that, perhaps it would be better to send text/html when the Textile filter is selected.

   Currently, we send application/xhtml+xml to all XHTML User-Agents (and to MathPlayer and the W3C Validator).

2. Do real content-negotiation for the Slide Notes page in the S5 view. Currently, IE gets text/html and everyone else gets application/xhtml+xml.

Since RedCloth is incapable of producing consistently well-formed output, we send text/html when the Textile (or RDoc or Mixed) filter is selected. With the Maruku-based filters (Markdown+*), we send application/xhtml+xml to all XHTML User-Agents (and to MathPlayer and the W3C Validator).

1. Are there well-formedness issues with Markdown+BlahTeX/PNG?

2. We should do real content-negotiation for the Slide Notes page in the S5 view. Currently, IE gets text/html and everyone else gets application/xhtml+xml.

Accessibility

1. There’s an excessive reliance on tiny fonts and low-contrast colours, in certain parts of the interface.
2. Make the Accesskeys in Instiki Editable.

S5 Integration

1. The S5 view works in Opera, but Safari’s Javascript support in real XHTML is rather broken (latest WebKit nightlies even crash on some slideshows). The only workaround had been to send the S5 slideshows to Safari as text/html. This is now fixed, but the code for working around Safari’s bugs could still be improved. Maybe, if Safari supported MathML, it might even be worth it.
2. The Slide Notes page, is served as text/html to IE, and as application/xhtml+xml to everyone else. This is suboptimal for MathPlayer users. But, given that IE’s rendering of S5 slideshows is suboptimal, anyway, perhaps it’s fair to assume that anyone delivering an S5 slideshow in Instiki isn’t using IE.
3. Maruku should have a syntax for entering Slide Notes.

Caching

Mostly, the algorithm for expiring cached pages works well. But, occasionally, it screws up, and you want to expire a cached page manually. If you have command-line access, that’s as simple as deleting the corresponding file from the cache directory. But many users won’t have command-line access. For them, it might be nice to create an interface to expire cached pages.

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 proxy Instiki through Apache, and use 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).

Performance

Let’s be blunt: Instiki is kinda slow. Some of this is because Ruby and Rails are kinda slow. Ruby 1.9 (when Rails becomes 1.9-ready) will provide a huge speed-boost.

But Instiki itself could probably be much accelerated, with some rewriting. It would be good to

1. Identify the bottlenecks.

2. Fix those things (besides Rails itself) that are not Ruby 1.9-ready.

   • In particular, Maruku and html5lib seem to be problem areas. But there are surely others.

Other

The main Instiki site has a TODO list of its own. Of particular interest, I think, are:

1. Interface to rename or delete individual pages.

   • Can easily delete selected pages using the “delete orphaned pages by category” function. Make sure there are no WikiLinks to the page(s) you want to delete, assign them to a category of their own, and then delete the orphaned pages in that category.
2. Interface to delete Webs.
   • Done.

Some other things which would be nice:

1. An interface to manage uploaded resources.
   • Done.

2. Themes.

   • Instiki offers a (somewhat lame) selection of the overall colour-scheme, and the ability to add per-Web CSS customizations. It would be better to offer Themes, as S5 does, where you can swap out the whole CSS file, and radically change the appearance.