Messages in this thread | | | Date | Wed, 30 Jun 1999 15:27:31 +1000 | From | Richard Gooch <> | Subject | Re: albods |
| |
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/
| |