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.
Hi :o)
I recently was looking for a small local standlone wiki to keep track of all the information I use at work, which is a lot.
I came across Swiki in my search and despite it being a beta decided to give it a go.
I have to say I love it, a truly brilliant little tool.
Simple and functional, something many developers miss in the drive to have new "features" is that an application shouldn't be a monster to use and Swiki is pure simplicity.
I understand the usefulness of being able to host a server version so that people can share a wiki but would it be better to have it as an option or perhaps a public aspect and a private aspect? (declare a page public type of thing?)
Keep up the excellent work and thanks for taking the time to create Swiki :o)
Thanks! I definitely want to keep a Desktop Tool, I just hit a brick wall that prevents me from adding Images to Posts, so I have to find a solution to that, which Cassini (or the newly announced IIS Express) may very well be.
Essentially, I have no good way to display images within the built-in Internet Explorer control. Having a Web Server would solve that. Another Issue I'm thinking about is storing the images in the database, but when starting SWiki I extract them into a temporary directory and use file:// links - that would actually work.
But yes, simplicity and speed are still the main features I want to have.
[...] been some time since I wrote a post about me re-thinking SWiki. In the meantime, I have experimented a bit with several approaches, and the recent announcements [...]
I just wanted to say that I agree completely with Shane, above. I only recently discovered SWiki and it really is a gem. In fact, aside from it's inability to post images, it is exactly what I've been looking for. (I create characters for my own projects and this allows me to write and organize profiles for them.) It actually surprises me that posting an image locally is so difficult, but then again programming is not something I know very much about. 🙂
I hope that you are still working on this project, though I understand how sometimes one needs to abandon an older project.
I've been pretty busy with a lot of other projects at the moment, but I still have SWiki on my list. The problem with images is just that somehow they need to be rendered into an existing page, and that's tricker than it should be.
Also I'd need a Version for Mac OS X and iOS for myself, so that adds more complexity. I mainly need to decide how to actually render the content on each platform (HTML, WPF/XPS, PDF)