DokuFS is a FUSE filesystem that allows you to mount a wiki:DokuWiki installation over XML-RPC into your local filesystem.

Two days ago already I've put a new release of DokuFS online into my new cgit installation. There is not only that new release available, but also the whole history, you are able to browse the code, …

But now coming to the important point: the release. It is built for the DokuWiki ♥ release 2009-02-14. First of all there is a completely new big feature: media support. You can upload any number of files by just copying them into the right directory of your mounted DokuWiki. In my opinion that is one of the best uses for DokuFS. Download is, of course, supported, too. At the moment there isn't any cache for media files, please let me know if you need/want that.

There are other smaller features, among others you can disable the cache to always have a fresh copy of your files and you can specify the number of seconds between updates. There were a lot of bugs and problems in the update routine, I'm not sure if it really worked at all. Now it should work. At least I tested it and after I had fixed a lot of things it did work. And it should even work when the local clock and the clock on the server are totally out of sync and in different time zones.

Another change is that I'm using a real option parser now, the options use two dashes now and the help message has a different format. This should give you better error messages as the old ones weren't that good.

There are some other changes I almost forgot as I've done them last August already. It concerns the fact that DokuFS is now not only storing the names of the pages but also a lot of meta data it gets from the wiki when asking for all pages (this feature has been implemented in DokuWiki in August, too). This means that DokuFS no longer has to load a page from the wiki in order to know it's size and there are much better permission checks, too. As well for existing as for non-existing files there is a real permission check before you can open that file for write which prevents you from writing a page you can't save afterwards.

As before you can download from dokufs.rb and the usage information can be found under DokuFS. And now you can also use the git repository of DokuFS.

Nevertheless I am also experiencing the limits of FuseFS, the Ruby interface for fuse I am using, that is a rather high-level one. At the beginning that was right, but now as I'm having more and more a full-featured filesystem with permissions etc. I am thinking about moving to another system. Although I really do like Ruby I am also thinking about moving to Python. This has multiple reasons. First of all there is chimeric working on DokuVimKi and a general Python lib for the XML-RPC interface of DokuWiki and there is Notefinder, another piece of software that uses the XML-RPC API of DokuWiki and Python, too. I don't see any sense in doing the same thing twice, that's why I would love to use and extend this python lib. Furthermore I have the impression, that the fuse interface for Python is better and better maintained (the last release is from 2007 in contrast to 2005). This is an impression from someone who has used none of the two full implementations (I use rfuse as comparison here, as it exposes more of the complete fuse api than FuseFS and as such it is similiar to python-fuse).

Before I can begin this conversion project I first of all have to learn Python, so don't expect anything soon. Perhaps it will still be in spring, but more probably it will be in the summer when you can see something from that new project. But one thing is sure: It will be maintained in the git repository I've already linked so you can probably follow the development from the beginning. And if you want to join it, just comment or mail me so we can coordinate.

The general trend is that we store more and more information no longer on our own computer, not on a server we control, but we give our information to a completely foreign company that does even reside in a different country. We give away the control over our data and often we can't even process that data anymore like we were used to.

But there are APIs, and these APIs do allow really cool things and some webapps do already allow cool things (e.g. you can import a table from Wikipedia in Google Spreadsheets and reexport it with Yahoo! Pipes and display the geographical information that was in that table using Google Maps, here is a German explanation how to do this). But let's bring it back to the basics - why can't we use the programs we are used to with our data that's elsewhere? Well, because it's not in our filesystem. But what if we could change that? And yes, we can.

There is flickrfs that allows you to browse photos from Flickr in your (Linux or Mac OS X) filesystem, and with gdatafs you can do the same with Picasa from Google. And for Google Docs, there is something similar: GDocsFS, though I am not sure if it already supports writing documents. In the Windows world it's a bit harder, but it seems there are efforts, to make things like flickrfs work on Windows, too.

There are also smaller things (compared to Flickr/Picasa) you can bring into your filesystem - like Wikis, including file uploads, for MediaWiki there is fuse-mediawiki, for DokuWiki my own, still under development DokuFS or Delicious, though I am still missing the real idea what to do with bookmarks in the filesystem (if you have any, please comment!), a prototype does already exist (but still read-only), see here.

In most cases we won't get our data back, in some cases we really can by copying the directories to our harddisk, but in all cases we get a lot more possibilities and apart from that, it's a lot of fun.

There are probably many more examples and yet more ideas what to with fuse and web-apps that have APIs, I would love to hear your thoughts!

PS: This article was written in GVim and posted with DokuFS.

I've just finished a new version of DokuFS, my FUSE for DokuWiki.

New features are:

• A cache (with memory limit)
• File size is now set properly (some graphical editors rely on that)
• Saving a file without content but a revision comment does no longer directly delete the file, but removes it from the directory listing (deleting the file was irritating some editors)
• Saving empty files doesn't change their content, this change was necessary because on an edit an empty file is saved first before the new content is saved.

All in all I have to say that writing a filesystem isn't that easy as I thought when your back-end isn't a traditional storage. The next features that will be implemented are permission-checking on client side and a check if the write was successful.

The filesystem can be found under dokufs.rb, usage information is under DokuFS.