Database File System

Courtesy of Slashdot, and not really about languages per se, just an interesting project that happens to have been written in OCaml, dbfs.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

KDE?!

this is in the windowing system. ok, it's proof of concept. but further down the page there's discussion of future work being in gnome - another desktop. shouldn't this be at the os level? what happens when i try to use this from a command line? am i just way behind the curve on the whole separation of desktop and os?

is this what microsoft are/were trying to do with longhorn/winfs (i think it's still happening, but they're having problems and are moving to different (sql) server code)?

on a related note, i received an old /rdb manual today from a colleague who was clearing out his office. it provides access to a relational database within the unix shell (embedded dsl) - neat.

"Desktop" vs. "OS"

andrew cooke: this is in the windowing system. ok, it's proof of concept. but further down the page there's discussion of future work being in gnome - another desktop. shouldn't this be at the os level? what happens when i try to use this from a command line? am i just way behind the curve on the whole separation of desktop and os?

It does seem a bit odd at first, doesn't it? But consider that these days it's not unusual at all for the "OS" to provide some sort of event notification mechanism (e.g. DNotify for Linux or kqueue for FreeBSD/Mac OS X). Reify these OS events into your GUI event-handling mechanism, and you can do some nice stuff, like, oh, I dunno, keeping your GUI's presentation of the state of the filesystem consistent with the actual state of the filesystem (something that not even the Mac OS X 10.3.5 Finder does correctly despite kqueue being available as of 10.3).

I feel compelled to point out that this isn't a new idea at all; the very first Macintosh used the VBL (vertical blanking) interrupt to poll the state of the custom-built Sony floppy drive to see if a disk had been inserted and, if so, reified that event as a "disk inserted event" that was delivered to the running application so that it could attempt to call MountVol(). The Lisa may have done something similar even earlier.

FS notification etc

Both KDE and GNOME already uses FAM to monitor FS events.

While it makes sense for many of these concepts to be available at the OS level, the kernel hackers are very conservative when it comes to these sorts of features - "it belongs in userspace!" is the common response to things like file metadata storage, for example. So the desktop developers have to muddle around for themselves without assuming anything more than 80s UNIX underneath.

I don't mean this as a slight on kernel developers, of course, just that desktop and kernel hackers seem to come from different worlds. Guys like Robert Love who are comfortable on either side are few and far between.

UI integration

The reason for UI integration is simple: integration with file open/save dialogs (so there isn't a second step: save file, then annotate with metadata, or, find file based on metadata, then copy filename into open-file dialog).

An application like this is perfect for a shared user space library (possibly talking directly to the DB server); there would ideally be a separate shared backend library that could be used by shell, KDE, Gnome, etc. plugins, as well as any sort of command line or graphical navigator/annotator tool. Maybe the libraries are already separated this way, but we haven't heard about it since only KDE screenshots are available :)

you might want to look at www.namesys.com/future_vision.html

Cheers,

Hans

Errata

You mean the whitepaper, previsouly discussed, cf. RDF and relational DBs.

ReiserFS internals aren't my bag, but it would be nice to get Windows and Mac versions that could live on their own disk partitions and work with the OS (before Longhorn ships).