Re-Thinking SWiki

Yesterday, I spent an hour setting up a Debian Linux VM to host a MediaWiki, which is now a 1.2 GB big folder in the /doc folder of a new project, checked into SVN. While I was doing that despite the utter stupidity behind it, I was remembering that I tried to create a better Wiki System a few months back with SWiki. Now SWiki is nice in theory, but I think I made some fundamentally wrong decisions in it's scope and in the end, I didn't want to use it myself for anything. So I was thinking again about what problem I tried to solve and what I want to achieve.

MediaWiki is a fantastic system, but it requires a LAMP Stack to really work, and the fact that all data is in a database doesn't make it very Source Control friendly. So I really wanted to solve two different problems: I wanted all the data in the file system, so that it can be checked into source control and easily be shared by other people. So no database server. But to share it with other people, they need to be easily able to read the files. I did not want an application that digs deep into the system. Ideally, I do not want to require installation at all and leave no marks in the system.

So the original SWiki solved problem 1 by using a SQLite Database. There is nothing wrong with using a database as long as it's 100% filesystem based. My attempt at Problem 2 was to host the Internet Explorer COM Object Microsoft exposes and feed it HTML. That way, I don't even need a web server. But that attempt ultimately proved a failure. I could not do much of the rich formatting I wanted, even embedding images was impossible. At some point I questioned whether my use of HTML was correct, or if I shouldn't just use RTF and embed stuff using OLE.

But my problem wasn't the Markup part. I like the WikiPlex markup, and the library is clean and extensible. I really didn't want to try using OLE/RTF as these technologies are not meant for human consumption. Also, I want to keep the ability to export the Wiki to HTML so that it can be hosted on a real web server if desired (e.g., the documentation section of a project).

So really, I need a Web Server. But I don't need a particularly "good" one, especially because I do not want a large "footprint" in the network. Really, running a web server is a great way to trigger all sorts of security software across the entire company. But without a webserver, SWiki is simply not good. So I've started looking at the Cassini Web Server, which is conveniently open source under Ms-PL. This is a great server for many reasons. One, it's 100% managed code, so it can be completely embedded in my app. But more importantly, it can be configured to only ever listen on local loopback, that is 127.0.0.1 for IPv4 or ::1 for IPv6. This may still trigger some security software, but it seals off the application from the network, so no interruption should be caused in theory.

Overall, this is a good compromise. I gain the ability to turn SWiki into a full-blown ASP.net application by simply bundling it with a lightweight web server and control utility, all while still being able to keep the data in a single file. So this is what I will do now. I haven't decided if I keep SQLite as database or use SQL Compact due to it's much better integration and if I'm able to offer an upgrade for databases between "SWiki old" and "SWiki new". I haven't even decided if I keep the name or change it, although the existence of another wiki by that name makes me want to change it.

The only thing I really have decided on is that it will support images and that it will still use WikiPlex as it's parser, all while still requiring .net 3.5 and all while - at it's core - still being a simple, standalone desktop wiki, although a little bit less simple than originally envisioned.