> 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
>
Pretty good summary , but ... Issues like user specific overrides of
components are really an application issue. As I've said before, the
kernel provides the ability to do things - it's up to the application
to accomplish goals with this ability. In this override case, the
'bundle' is the base application and the application would need
to provide for user override of the base. As an example, KDE has
icons, themes, wallpaper, etc. for the installation (base bundle), but
a user may replace or supplement this with his/her own versions.
The bundle doesn't change, but there may be another bundle in the
user's home that the application uses to override.
Of course, if the bundle is a user's private application, he can just
'cp new bundle/old' and the element is replaced. This is why I want
a tag or signature that indicates that the bundle is not in a pristine
form.
Putting things together in an 'archive' (as you put it) is mandatory
IMO. The entire issue is that many items simply have no
significance on their own. It is only when bundled with other items
that they become significant. This can very from simple international
strings and icons, to entire application suites. Does it make sense to
have a utility that manages FooBar Document Folders when you
don't have the FooBar Application to create the document?
It is these two issues - grouping and the meta-tags you mention -
that started me on this path to begin with. The kernel shouldn't
care about the content and use of these 'bundles' beyond allowing
proper access to them. I've been pushing a definition of 'proper' as
defaulting to file system view - even while implemented as a simple
'archive'.
I've started work on a standalone application that creates and
manipulates a meta-file with tags. Hopefully I'll get it done this
weekend and post it so people can play with the idea. It won't be
complete as you cannot execute an application from within it,
but it should point out what can be done using the meta idea (pun?).
[Won't be easy ... there's an air show in my backyard and I keep
running outside to watch!]
-
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/