Re: albods

Richard Gooch (rgooch@atnf.csiro.au)
Wed, 30 Jun 1999 15:27:31 +1000

Mark-Andre Hopf writes:
> On Tue, 29 Jun 1999, Jamie Lokier wrote:
>
> > Richard Gooch wrote:
> > > Secondly, we haven't seen a convincining argument as to why putting a
> > > FS into a file provides a significant benefit.
> >=20
> > You know, you're right...
>
> =2E..
>
> > A fair point, though I haven't seen a convincing argument why a plain
> > old directory isn't adequate for holding a compound document.
>
> (a) Because it prevents the normal user from messing around with the
> internal of the `directory' and with it preventing the application
> programmer from adding tons of code to detect and workaround unexpected
> changes.

Letting the user mess around with the internals of a directory-based
albod is a *feature*. I will refuse to use a system that bars me from
doing that. Barring access to the individual "data forks" is a
restriction in flexibility. The lowest levels must present the data
forks as files.

In the GUI, however, you can pretend the albod is atomic (although,
again, it would be wise to provide an option to "break" the albod).

> (b) The normal user expects a `bunch of data' in a single file, not in a
> directory.

The normal user will be using a GUI, and thus will see the albod as an
atomic piece of data.

> (c) The content of the `directory' isn't of interest to the user but
> to some applications.

The contents of the directory are not of interest to regular lusers
who can only use the GUI. Power users will definately want to get in
under the hood.

Regards,

Richard....

-
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/