Re: The argument for fs assistance in handling archives

Stephan von Krawczynski
2004-09-04T11:42:31Z

On Fri, 03 Sep 2004 19:13:31 -0500
David Masover <ninja@slaphack.com> wrote:

> | Just choose the right program. tar groks tar files, not ls.
>
> tar groks tar. bzip2 groks bz2. gzip groks gz. "mount -o loop" groks
> images. zip groks zip. rar groks rar. openoffice groks .sxw, unless
> staroffice does. xmms can read id3 info from mp3s. gcc compiles C.
>
> If the file is an object, it's easier. You can ask the file what it is,
> and what you can do with it. And you can tell it to do certain standard
> things. You can do all of this while reading almost no documentation on
> what the file is. At the end of the day, it won't matter to you whether
> a file is zip, rar, or tar -- it's an archive, and you can extract it by
> copying files out of its /contents directory.
>
> Your way (the traditional way) means you have to learn to use which
> program is the right program and how to use that program, and you'll
> have to remember it constantly.

Just a short input from someone listening quite a while to this thread:
I think your approach to the problem leads actually nowhere. The reason for
this is implicit in your own explanation. _Currently_ you talk of archives, but
as soon as you got that, what's next?
Your idea needs abstraction, then you see the problem more clearly:
An archive is only some sort of file type, just as (you already named) mp3 or
.sxw is another type. If you really want to do something _generally_ useful you
should think of a method to parse and use all kinds of filetypes and create an
interface for that.
And one thing is clear: as there are numerous different types you cannot pull
all that code inside the kernel. Obviously there should be a way some
application can install a hook, a helper, a plugin or whatever to provide
extended functionality on its special filetypes. If you don't want to use tar,
you don't need the plugin either.
If you want tar, you should (as a user) be able to install the "fs-plugin"
(just a name, do not shoot me for it) together with tar as an application. You
get the idea? Obviously this must be possible during runtime, everything else
is senseless.
So, please, if you go on investigating this whole stuff do it in a more general
way, because "tar inside kernel" is not really what your idea is all about, no?
And one last obvious thing: if one doesn't want this kind of file-handling, he
should not need it. It has to be an add-on functionality, not a replacement.

Regards,
Stephan