I’ve run into a couple of more bugs relating to handling of the target attribute and recursion loops and have also recently learned about SQL relational object pointers which may be a canidate for replacing the target attribute and XML database format entirely. The command syntax may be able to be kept the same with the exception of the XPATH and XPATHATTR commands. But SQL has easier searching syntax anyway.
Hopefully we should be able to use sqlite3 since it can do in-memory databases and possibly faster than the XML database, too. We’ll see how it goes…
UPDATE: There is a project libsqlfs that utilizes sqlite’s VFS features as a fuse module. The fuse module itself isn’t very useful because fuse is Linux and *BSD (just looking at configure.ac) specific and not portable to other OS’s. Most filesystem operations can be done without the fuse parts with the exception (naturally) of symbolic links. I’ve got a somewhat working implementation of sqlfs_proc_realpath() that may be a suitable substitute for the "target" attribute.
Since the VFS features of sqlite are being used, most commands will probably change to look and behave like shell commands: cp, mv, ln, rm, etc.
UPDATE 2: Well, I don’t think SQLite is going to work as well as I thought. So I’m going to rewrite how the “target” attribute works by removing the notion of literal elements to simplify things. An element with a “target” attribute will work as usual, but a literal element — the element of the same name without a “target” attribute — will be non-existant. So if you remove an element that contains a “target” attribute, it will remove only that element and not the target element path. Kinda like removing a symbolic link on a filesystem. Remove the link and not the stuff the link points to. Thats the new plan. But things may of course change.
bjk's blog 