Re: we missed something wrt albods

Larry Butler (larry@astronom.fc.hp.com)
Thu, 01 Jul 1999 12:24:00 -0600

Rik van Riel wrote:
>
> What we need is a way to have _both_ possibilities. Even a
> (gross) hack to do both is better than to run into the problem
> you paint above.
>
> Maybe we want to just list "file" as a standard file with the
> dir listing but be able to open "\file" as an albod directory
> when we ask for it. Most (almost all) non-albod-aware programs
> have the possibility of explicitly entering a file/dir name to
> perform an action on so it will just be a minor inconvenience
> while some system tools will be converted.
>
> Besides, when you use file/logo.gif the system doesn't have
> to guess what you want to do so it'll be not that much of a
> problem once we've got a method in place of accessing an albod
> in both ways.

So, I see no way that this can be transparent to the user with
non-albod-aware applications.

Just imagine:

$ ls -l
total 2
-rw-r--r-- 1 larry users 13 Jul 1 11:59 file.c
ls
$ ls -l \\file.c\
total 6
-rw-r--r-- 1 larry users 789 Jul 1 12:02 default
-rw-r--r-- 1 larry users 456 Jul 1 12:02 fancy-editor-saved-state
-rw-r--r-- 1 larry users 123 Jul 1 12:02 icon
$ vi \\file.c/default (a big pain)
$ gcc \\file.c/default (oh no, gcc doesn't even know its a .c file!)

Nobody will use this for files that don't strictly have to be in
albod format unless *everything* is albod-aware. Otherwise it will
be a big pain no matter where it is implemented.

As for applications that are written specifically to use albods,
they could just as easily use a fancy file format and not be
limited to one FS on one OS.

-Larry

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/