|
|
Introduction
This is a (at the moment draft) FAQ for Yaki that aims to cover all the basics. If you'd like to see anything else covered here, please file an issue.
Generics
Why Another Wiki?
Well, mostly because I was somewhat unhappy with PhpWiki's reliance on a mySQL database, and wanted a filesystem-based Wiki engine to support The Tao of Mac.
The PhpWiki codebase I used was forked from a very early version and was becoming hard to enhance/maintain, and I didn't want to rely on PHP's vagarities where it concerned versioning (different versions have wildly different bugs at many levels) and extensions (I relied on a few extensions that were not usually included in common Linux distributions).
What do I need to get it running?
Currently, you just need Python. Everything else is included.
In the future, you may (or may not) require ImageMagick for image processing (I have no intention whatsoever of using PIL, since it would significantly increase complexity).
On What Platforms Does It Run?
Yaki has been tested on the following platforms:
| OS | CPU | Python | Notes |
| Mac OS X | PowerPC | Stock Python 2.3.5 | No issues |
| Mac OS X | Intel | MacPorts Python 2.4 | No issues |
| Linux (CentOS) | Intel | Python 2.3.4 | Main production environment for The Tao of Mac, some FutureWarnings (no runtime issues) |
| Linux (Unslung) | ARM | Python 2.4.4 | Main testing environment (no issues) |
| Windows (Cygwin) | Intel | Python 2.4 | No issues |
Since it relies on UNIX path semantics internally, Yaki is unlikely to run on Win32 Python without some tweaking.
This is not likely to change unless someone contributes the required patches.
A note on memory requirements:
The main testing environment is a Linksys NSLU2 with 32MB of RAM, on which Yaki performs beautifully. The Tao of Mac instance takes up 80MB of RAM when running, due to runtime contexts and some page metadata stored in RAM.
How Can I Edit via a Browser?
You can't. I have always found browser-based editing to be insecure and fraught with pitfalls, so I left it out, since I am perfectly happy with editing pages on the filesystem (which was the whole point of my implementing Yaki in the first place).
There is embryonic code to allow for saving pages that can be used to implement that, and Snakelet's nature makes it very easy to implement a completely separate online editor that does not interfere with the basic Yaki code.
So feel free to have a go at it yourself. Snakelets makes it a pleasure to write web-based Python apps, and I recommend it.
Right now, the recommended way to edit Yaki pages is to use a powerful text editor like TextMate or vim.
In the future, I'm considering supporting XHTML pages (such as those produced by Nvu and other HTML editors) directly - Yaki processes everything as HTML internally anyway, and the only real issue is handling page metadata in a sensible way.
Where's WYSIWYG Editing?
See the previous FAQ. Besides the security issues, the lack of a decent, completely cross-platform WYSIWYG editor (i.e., one that would work properly in Windows, Linux and the Mac more or less regardless of browser) was another reason why I didn't go for online editing - Wiki markup will only go so far, and I'm willing to wait until I can deliver a truly decent user experience for online editing.
And yes, I've tried all the usual JavaScript-based editors (and a few Flash editors as well). None of them are really up to scratch yet, as far as I'm concerned.
What Kind of Markup Does Yaki Support?
Right now, it supports straight-up HTML, Textile and Markdown.
Since everything is processed internally as HTML thanks to the utterly, utterly, amazing BeautifulSoup, it can support just about anything else as long as you have Python code for it.
(all Wiki pages are pre-rendered into HTML and processed, so adding other filters is trivial - check the Page class implementation)
Patches/filters for other markups are therefore most welcome.
Right now, the most requested ones are:
- Google Docs Wiki markup
- Wikipedia markup
- MoinMoin markup
Do you support CamelCase?
Not at the moment, no. I find it an anachronistic nuisance, but it can be bolted on with minimum hassle - you just have to include it as part of any new markup filters, since the core Wiki engine is completely agnostic as to what constitutes a link.
How Fast Is It?
Well, I have not run formal benchmarks, but the Snakelets engine is a marvel of efficiency (even considering that it's HTTP/1.0 and doesn't have very sophisticated features), and it has been keeping my site ticking over with nearly zero CPU load.
Then again, it is extremely aggressive in terms of caching (it sends out a few extra headers besides the Snakelets defauls) and is developed on a modified Linksys NSLU2 with 32MB of RAM, so I suppose it will scale fairly well.
How Can I Make It Even Faster?
Well, there's two things that I do that you might find handy:
- Use lighttpd as a reverse proxy (and as an HTTP/1.1 front-end, therefore reducing the overhead of setting up consecutive TCP connections for some browsers)
- Install the sendfile() module mentioned in the Snakelets documentation.
I am also tinkering with the notion of using the lighttpd caching module to further accelerate the process of serving static files, but have decided to hold off until their 1.5.0 branch becomes stable (since 1.4.x does not have all the desired features)
Sign in to add a comment
