I've thought about FUSE filesystems before, as a way to express a data container based language (such as APL, SmallTalk, MUMPS, etc.) as a Unix/Linux filesystem. Basically as a tool to expose the internal data and allow external tools the ability to process the data. Is there anything written that might talk about PROs and CONs in the design process for these?
Only tangentially related, but my favourite example of exposing (albeit simple) internal data as a filesystem is FrexxEd. FrexxEd is an AmigaOS editor co-written (in C) by the creator of curl back in the 90's that makes all open buffers accessible as a filesystem.
It was particularly compelling back then when saving a buffer to a temporary file in worst case could involve swapping floppies, but I've always liked the elegance of being able to call external tools and let them read the buffer directly.
I'd imagine the major con in general is that if you want to use it to actually operate on the data, lots of files is slow (open, read/write/seek, close cycle involves many context switches), but making structured data accessible as few files means structured files and potentially complicated locking - the FrexxEd example above is close to the ideal case in terms of simplicity of exporting the data in an efficient way.
This resonated with me somehow, despite never using AmigaOS... And then I realized TotalCommander can also treat archives as folders (aside from solid RARs, I suppose).
While that is true, that was an application-level implementation.
With an OS-level file-system implementation, I could in any application just double-click a ZIP file, open a GIF or JPG inside it, make my changes and save back and the ZIP was now updated.
It was one of those small things which made a huge difference in the user-experience.
In a similar vein, here's an XPK filesystem handler [1]. XPK provides a system for anyone to write their own compression/decompression libraries. Anything that uses XPK will handle whichever compression format you have an XPK library for, entirely transparently (many applications have application level support for XPK too, but the filesystem handler is much more generic)
6 comments
[ 4.7 ms ] story [ 44.8 ms ] threadIt was particularly compelling back then when saving a buffer to a temporary file in worst case could involve swapping floppies, but I've always liked the elegance of being able to call external tools and let them read the buffer directly.
I'd imagine the major con in general is that if you want to use it to actually operate on the data, lots of files is slow (open, read/write/seek, close cycle involves many context switches), but making structured data accessible as few files means structured files and potentially complicated locking - the FrexxEd example above is close to the ideal case in terms of simplicity of exporting the data in an efficient way.
You would just cd into the file and the rest was magic. I've always missed that feature since moving to the PC.
In lots of ways, AmigaOS was way ahead of its time.
With an OS-level file-system implementation, I could in any application just double-click a ZIP file, open a GIF or JPG inside it, make my changes and save back and the ZIP was now updated.
It was one of those small things which made a huge difference in the user-experience.
[1] PPC: http://www.a500.org/downloads/filesystems/xfh-handler_lha.re... M68k: http://aminet.net/package/util/pack/XFH