Content-space.de

The WikiBlog of Michael Hamann about changing technologies and more

User Tools

Site Tools


start

Home

Welcome on my WikiBlog! You can find a mixed collection of German and English content here. This website is always work in progress as there is a lot to do and so little time.

Willkommen auf meinem WikiBlog! Hier gibt es eine Mischung aus deutschen und englischen Inhalten. Meistens habe ich zu viele Ideen und zu wenig Zeit und so ist auch diese Website eine ständige Baustelle.

Gedanken zu Social Bookmarks

Als im Februar der Social Bookmark Service Taggle.de von Mister Wong übernommen wurde, habe ich mir einige Gedanken darüber gemacht, was mir Social Bookmarks bringen, was ich da will und was ich mit meinen ca. 600 Bookmarks, die ich dort gesammelt hatte, machen will.

Was fand ich bei Taggle.de gut?

Hm, zuerst einmal, wie ich zu Taggle.de gekommen bin - Martin Mündlein hat mich persönlich auf Grund eines Eintrages hier im Blog angeschrieben. Obwohl mich die Qualität des HTML-Codes von Taggle.de eher abgeschreckt hat, habe ich mich daraufhin entschlossen, mich zu registrieren. Vor allem deshalb, weil ich bei Taggle.de sehr interessante Bookmarks gefunden habe. Auf der Startseite waren sehr oft Links zu Web2.0-bezogenen Themen zu finden, sogar das Wort Web2.0, das ich davor noch gar nicht kann, habe ich auf diese Weiße kennen gelernt. Auch auf Anfragen nach Features wurde schnell reagiert, wenn auch nicht alles Versprochene umgesetzt wurde. Auch dass Taggle.de ein Studentenprojekt und nicht primär von einer Firma war, fand ich gut. Klar, technisch war es nicht der Hit, es gab zwei Mal - so weit ich mich erinnern kann - einen längeren Ausfall, die Tag-Vervollständigung war bei meinen vielen Tags nicht mehr wirklich schneller als das Tippen bzw. das Tippen wurde durch sie sehr erschwert, aber dennoch fand ich einfach sozusagen die Community gut.

Was möchte ich für meine Bookmarks in der Zukunft?

Möchte ich überhaupt Social Bookmarks? Also mir ist klar:

  • ich möchte auf die Bookmarks von überall aus zugreifen können
  • ich möchte meine Bookmarks auch anderen zeigen können
  • ich möchte Tags
  • der Service sollte einigermaßen gut erreichbar sein (Ausfälle/Geschwindigkeit)

Doch was bringt mir jetzt ein Social Bookmarks-Service gegenüber einer Applikation die auf meinem Webspace läuft (wie z.B. Scuttle)? Hm, ich sehe, wie populär ein Link ist - doch das interessiert mich eigentlich wenig und es hat auch nur bei den großen Seiten wie del.icio.us wirklich ein wenig Relevanz. Aber etwas anderes ist es: ich sehe, welche Tags andere dieser Seite gegeben haben. Und das finde ich echt praktisch, denn es erleichtert einem das Bookmarken ziemlich.

Meine Entscheidung fiel letzten Endes zu Gunsten von del.icio.us und gegen Mister Wong, auch wenn ich mir dort auch erstmal einen Account erstellt und meine Bookmarks importiert habe.

Weshalb del.icio.us? Zum einen ist es dort sehr wahrscheinlich, dass jemand die Seite schon einmal gebookmarkt hat und deshalb bereits schon Tags vorhanden sind. Zum anderen ist ein Ausfall der Seite recht unwahrscheinlich. Außerdem gibt es für del.icio.us für sehr viele Programme (auch Blog-Systeme) Plugins, mit denen man del.icio.us integrieren kann. Scuttle würde diese API, die hier Verwendung findet, auch anbieten, da spielt aber dann die Community die entscheidende Rolle in meiner Entscheidung zu. Was mich letzten Endes überzeugt hat, war der Ruby-wmii Bookmark Manager - ich setzte davor bereits wmii mit der Ruby-Konfiguration ein und hatte das ganze somit schon installiert - und so habe ich nun eine immer (alle 30 Minuten) aktuelle Kopie meiner Bookmarks auf dem PC (d.h. ein aktuelles Backup, ich habe also meine Bookmarks auch zur Verfügung wenn del.icio.us/mein Account mal nicht erreichbar sein sollte) und komme über ein Tastenkürzel sehr schnell an meine sehr schnell und super durchsuchbaren Bookmarks dran - echt klasse! Und zum Hinzufügen klicke ich auf den passenden Button in Firefox und kann die vielen Tags der anderen Benutzer nutzen - auch Klasse! Und ganz am Schluss nun noch ein Link zu meinem Account bei del.icio.us.

DokuFS release 2009-02-24

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.

DokuFS 2008-06-21

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.

start.txt · Last modified: 2013/03/09 01:37 by michitux