## Introduction The idea behind file system translators is a powerful concept which hasn't recieved much attention in the mainstream computing world. So here is a list of interesting translators I've been able to dream up. I'm sure there are many more ideas floating around out there, so add them to the list! ## Audio\_cdfs A translator which produces a directory of \*.wav files when you have an audio CD in the drive. ## Ogg This translator could be a sub-directory of the Audio\_cdfs translator and it would translate the \*.wav files into Ogg Vorbis/MP3 format. ## CDDB Of course it would be a lot nicer if the above two translators didn't name their files something worthless like track001.ogg. So we would want a translator which would hook up with a database on the web and produce meaningful file names. ## Crypto A cryptographic/steganographic seem like a nice match with the concept of user-land file systems. I like the idea of something like `settrans -a /secure stegfs --mpeg file001.mpg` ## Revision control All of the empty space on your drive is now being wasted. Why not have a revision control translator which tracks changes to your documents? ## tar and gzip Rumor has it that they are on the way. ## ROM How about a translator which makes it look like you can write to read only media (like CDs), or change files which I don't have permission to change. This translator would make it seem like you could copy files to places where you normally couldn't. Think about combining this translator with the ftp translator and the tar and gzip translators. (cd /ftp/gnu.org/gnome.tar.gz/writes\_allowed; make install). It could be that unionfs does this very thing. ## Super\_FIFO It's like a named pipe which is smart enough to start a process everytime something new tries to read from it. For example, let's say I have a script that reads in a JPEG image and spits out a smaller thumbnail \*.jpg to STDOUT. With a standard fifo (`mknod -p fifo`) this would almost works (`script big.jpg > fifo`). But what if there are two processes trying to read the fifo at once? Ick. And of course the standard way only works once without rerunning the command. I'm not quite sure what the syntax should look like, but I'm sure someone out there has a great idea waiting to happen. ## Perl Perl is a wonderful language for hacking together something useful in a short amount of time. No concept is complete without being able to use it in a perl one-liner. And that goes for Hurd translators too. Right? #!/usr/bin/perl use Hurd::translator; #file named "two" can produce an endless supply of twos, etc. (a la /dev/zero) my $i=0; for $filename ([zero one two three four]) { $libtrivfsread_codehash{$filename}= sub{ $num_bytes=shift; my $data=$i; return chr($data) x $num_bytes; }; #that's a hash of references to closures $i++; } translator_startup(); ## Source code Here's a crazy thought. How about a translator for source code. You have a C source file like `hello.c` which is your normal everyday file. But there's a translator sitting underneath, so when you `cd hello.c` you get a directory with files like `main()` which represent the subroutines in `hello.c`. And of course you should be able to edit/remove those and have it modify the original source. ## Libraries Here's an [idea](http://www.circlemud.org/~jelson/software/fusd/docs/node13.html) from the people making [userspace drivers in Linux](http://www.circlemud.org/~jelson/software/fusd/): * "One particularly interesting application of FUSD that we've found very useful is as a way to let regular user-space libraries export device file APIs. For example, imagine you had a library which factored large composite numbers. Typically, it might have a C interface--say, a function called `int *factorize(int bignum)`. With FUSD, it's possible to create a device file interface--say, a device called `/dev/factorize` to which clients can `write(2)` a big number, then `read(2)` back its factors. * This may sound strange, but device file APIs have at least three advantages over a typical library API. First, it becomes much more language independent--any language that can make system calls can access the factorization library. Second, the factorization code is running in a different address space; if it crashes, it won't crash or corrupt the caller. Third, and most interestingly, it is possible to use `select(2)` to wait for the factorization to complete. `select(2)` would make it easy for a client to factor a large number while remaining responsive to other events that might happen in the meantime. In other words, FUSD allows normal user-space libraries to integrate seamlessly with UNIX's existing, POSIX-standard event notification interface: `select(2)`." ## Mail Am I off my rocker, or does an IMAP/POP translator sound like a good idea? It would make your remote mail servers look like local ones. Or what about a translator that makes a mbox format mail spool look like a directory. Can anyone think of a good use for an SMTP translator? ## UUEncode How about a UUEncode translator for those places you can only store ASCII. Combine this with a NNTP translator and store your data in someone's Usenet archive. Or since, (as far as I know), there are no size limitations on file names in the Hurd, why not have a filesystem translator whose underlying store is a file name. (Now ls becomes cat). ## Computation This is from the revenge of the command-line department. Make a directory translator whose contents are a result of the computation specified in the directory name. Here's an example... $ settrans -a /comp /hurd/computationfs $ cd "/comp/3+4" $ ls -l total 0 -rw-r--r-- 1 nobody users 0 Oct 16 11:41 7 $ $ cd "/comp/sqrt(2)" $ ls -l total 0 -rw-r--r-- 1 nobody users 0 Oct 16 11:42 1.4142135623731 $ ...etc. Now think about your favorite GUI HTML editor and using File->Open on the following directory name, ``"/comp/for i in $( find / -name *.html ); do ln -s $i `basename $i`;done"`` Which would produce a directory listing with soft links to all of the \*.html files on your system. You could have all of the comforts of the shell from within that little File->Open dialog box. -- [[Main/GregBuchholz]] - updated 16 Oct 2003