libferris

libferris is a virtual filesystem that runs in the user address space and can be exposed through FUSE. I have focused on the FUSE binding at my OLS 2007 talk where I built up the use of the untouched rsync tool with libferris-FUSE mount points at each end from a simple example to syncing between PostgreSQL databases.

There are a few dragons to the later because you can't just create "a file" in a mounted postgresql database table, you always have to supply atleast the primary key material and if you have a decent db design the foreign keys too. The FUSE binding to libferris has been extended to allow the toughest case to work: syncing data into a postgresql table. Options were needed to inform the FUSE binding of what data it should wait for before it actually performs the underlying writes to the libferris API. Incidentally, this is not the only place in libferris where delayed writes are imperative. When you are performing an action like applying XSLT like the xsltfs: filesystem does, you can only get acceptable performance if you have libferris hold off write commits for output XML files until the entire transform is complete.

For these next examples, keep in mind that libferris sees XML as a filesystem (you can mount XML), and a filesystem as XML (you can get a shallow DOM from any libferris virtual filessytem). Also note that explicit mount operations are not really used in libferris. If you want to dig into a Berkeley db or XML file, just fcat /tmp/foo.xml/root/fred directly. Also if you want to get at postgresql data, use postgresql:localhost/mydb/mytable etc. This is an important point when combined with the exposing of libferris through a DOM or XQilla interface as you can get to a whole bunch of data through a single "document".

The combination of libferris-FUSE and xsltfs: allows for some interesting possibilities. One example is that libferris supports geotagging. Of course, libferris being a virtual filesystem, and me being who I am, you can access your geotags as a virtual filesystem though libferris. Unfortunately, writing digital longitude and latitude values into these virtual files is not the most human friendly interface. Using the thumb markers in google earth is a much simpler way to record places of interest. To solve this, I use xsltfs: to transform the geotag filesystem into a virtual filesystem that has the same schema as a KML file. Then, using libferris-FUSE I expose this KML filesystem as a single file though the kernel. Google earth can then open this "file" and your geotags appear as thumb markers in the app. The fun part comes when you add some more markers in google earth and press save. The file is written back the the libferris-FUSE file which then causes libferris to apply a reverse XSLT to the data and update its geotag filesystem. So you get to use an application that is specialized at editing a type of information, with no changes at all to that application, but you are editing very strange data instead of normal KML files.

Another example of the libferris-FUSE and xsltfs: combination is using OpenOffice to edit data stored in PostgreSQL databases or RDF stores. libferris applies transformations for you in its xsltfs: implementation and you expose office documents through FUSE that OpenOffice reads and writes.