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/