Not-so-magic VFSs

["D. Diederen" <D Diederen student ulg ac be>]

<WARNING>
	Long post and bad english follows
</WARNING>

[clip]
> the directory containing the menu items. Most of this is addressed by that
> old "Simplified Virtual File System" idea.
> 
> If there is no simplified virtual filesystem, the directory full of
[clip]

About the (S?)VFS:

I don't know if GNOME is already using a VFS like KDE does, but I would like to
say something:

KDE is using "URLs" like:
	file:/whatever/dir/you/choose/file.txt
	info:(whatever)Top
	etc.
MC is using "URLs" like:
	/a/directory/path/file.txt
	tar:/directory/file.tar.gz/in/the/file (IIRC)
	etc.

These are working pretty well, but have some limitations: what it the user
wants to browse an info file that is archived in a zip one ? And what if an
user wants to have a look in a zip file on a ftp server without downloading it
? AFAIK, it's impossible without "manual" intervention. 
I was thinking about that problem when I (perhaps) came up with a "solution":
the "nested" URLs. Let me explain the rules:

	The URL separator is "://"
	An URL is parsed right-to-left
	They are "terminal" and "non-terminal" URL types. file:// is a terminal url,
because it doesn't need the help of any other to provide data, while zip:// is
a non-terminal one because it needs to get the archive.zip file from another
file system.

So we end up with URLs like:
	/usr/bin/file (== file://usr/bin/file)
	~/src/test.c (== file://home/dir/src/test.c)
	src/test.c (== file://present/working/dir/src/test.c)
	ftp://ftp.dumb.org/pub/test.c (ftp = terminal target)
	~/arch/zip://test.zip/test.c (hehe a zip file = non-teminal)
	ftp://ftp.dumb.org/pub/zip://test.zip/test.c (hehehehe)
	~/arch/tar://test.tar.gz/inside/tar/zip://nested.zip/inside/zip/info://libc.inf
o/Top
	etc.

Of course, a thing like
	ftp://ftp.dumb.org/pub/file://usr/local/bin
would be valid, while useless.

How it works: Let's have a look at how works an URL like
	~/arch/tar://test.tar.gz/zip://test.zip/test.c

1) The url parser splits the url in (from right to left, remember !)
	~/arch/tar://test.tar.gz/  -  zip  -  test.zip/test.c
2) The zip plugin is called with the three parameters
3) The zip plugin opens the file ~/arch/tar://test.tar.gz/test.zip thru the VFS
4) The url parser splits it in 
	~/arch/  -  tar  -  test.tar.gz/test.zip
5) The tar plugins opens ~/arch/test.tar.gz
6) The url parser splits it in
	(nothing)  -  file  -  ~/arch.test.tar.gz
7) file reads a bunch of bytes from ~/arch.test.tar.gz
8) tar extracts the bytes it needs from the vfs
9) zip uncompresses the bytes it gets to test.c

Whoo... It was a pretty long (and stupid) example, but you've got the thing. Of
course there could be a lot of nice things with this scheme:

- If the foo archive type has a directory header, the foo plugin can: open
file.foo, read only the directory, jump to the location where the data needed
is located in the archive, and read it. Interesting when used via FTP, isn't it
?. 
- If the user wants to add a file to a .tar.gz archive, the tar plugin should:
check its config., issue a warning (lenghty operation) if warnings==yes in the
config., gunzip the .tar.gz in /tmp, add the file to the tar, gzip the new tar
to remplace the current one. All this is happening _transparently_. It would be
nice to notice Joe user when he wants to update a .tar.gz via ftp, of course
:).
- *any* app. linked with that "libVFS" dll would of course be able to do all
these things.

Target aliases would also be interesting, in the spirit of the Midnight
Commander's virtual file system "extfs" target. One would alias "bz2 == extfs"
and write a little shell script to provide bzip2 functionnality to _every_
libVFS app.

In the case somebody is interested, I can provide a bunch of *experimental*
code. The VFS is implemented, as well as plugin dynamic loading, and it _works_
(hmm, at least with the terminal "file" target, and a "dummy" non-terminal
target that is just a dummy filter).

CU,
Damien

------------------------------------------------------------------
- DIEDEREN Damien                  2e Candi. Ingénieur Civil ULg -
------------------------------------------------------------------
- Rue E. Vandervelde, 545 - 4610 Bellaire (Belgium)              -
- Tel / Fax : 32-4-362.65.28                                     -
- E-Mail : D.Diederen@student.ulg.ac.be                          -
- Home Page : http://www.geocities.com/SiliconValley/Haven/6226/ -
------------------------------------------------------------------