Messages in this thread | | | From | Michal Jaegermann <> | Subject | Re: albods are not a clean set of orthogonal primitives (was Re: File systems are semantically impoverished compared to database and keyword systems: it is time to change!) | Date | Fri, 25 Jun 1999 10:57:39 -0600 (MDT) |
| |
As a long time owner of NeXT I accumulated some experience with albods (Meta-Files, bundles, app folders, whatever you may want to call it). In a comparison what Mac is doing with that, and with which I also had a bit of a contact, is heavily brain-damaged. Mac system is somewhat workable, barely - if that, on a single user, isolated, machine but put it in a some mixed environment and nasty hacks are immediately required. Looking back from my years of using the stuff I think that Wanderers <jmills@portland.quik.com> proposal of keeping things simply as directories, not excluding even directory tries, with some extra tags for programs which can handle additional functionality (and some other details of this proposal) is on the right track.
NeXT is using a very simple minded, not to say trivial, meta-tag. This is simply an ".app" suffix on a directory name. It may be not good enough on a long run but it worked quite well for a while and I do not recall this to be ever a major concern. It is true that command line tools allow you dive in directly into "app folder" and you have to use GUI to see it as a whole. Actually even GUI has a non-default option to "open app folder as a directory" and manipulate files inside. And, contrary to what some people were saying in this thread, this is a GOOD THING (TM). This capability is not used directly very often but sometimes, when is needed, is invaluable.
Proposals to pack the whole bundle in one archive, be it tar, cpio, ar, whatever..., in order to make sure that users will not screw up and separate parts from a whole are IMO excessive. Without special tools on hand to manipulate a bundle contents you are SOL and quite sizeable experience accumulated on NeXT, with users of all kinds - not necessarily computer propeller heads :-) - shows that in practice such protection is NOT a concern. A long standing Unix tradition is that you are not prevented from doing dumb things because this could also bar you from doing smart things. I would be firmly against of starting with that on a dumbing down slippery slope. Various tools, GUI viewers, etc. may, and should by a default, show and manipulate such albod as an aggregate but from the point of view of a file system and "regular" utilities this **should not** be something special. Think for a moment about backing this up on a remote tape drive hosted by a machine with a totally different OS; or by replacing an application icon by something cool your friend just e-mailed you. :-)
This reminds me; it also **should** be possible to substitute individual bundle components on an account-by-account basis and keeping albod components as separate entities in a file system makes that much easier (some link conventions? I do not know at this moment but this is an implementation detail; the point is that a general design should not make things like that hard or extremely hacky). And I am not talking here only about icons. Generally I do not reimplement my private 'ls', even if I can, but if "I" am an "ftp" user I may want to have my own 'ls' version and often I actually do.
Once everybody and his brother-in-law moved to an object oriented storage system then albod will be simple an object (not in an EROS sense but as a single storage entity). But it looks like that this will not happen for a while yet. :-)
What all of this has to do with the kernel? Depending on results of this discussions one would need more or less intervention in kernels to make the whole thing feasible; and I think the less kernel knows about it the better. Maybe we would need a way to inform VFS "here lie some meta-tags" but this should be about it. An interpretation of semantics of these meta-tags, with a possible exception of some security related bits, should be a business of a user space.
Michal michal@harddata.com
- 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/
| |