.bundle/bin
.bundle/man
[...]
for some reason, i have a strange fondness for AppleDouble style forks
that do the "main file" + bits. i think it's because i know what to
expect there. in any case, having it be more generic than that would
also work. i'm not quite sure i understand what your syntax is really
saying though. do you want to a single bundle with bin and man
together or separate bundles called bin and man?
Wait, let's call it `package' instead of `.bundle'.
I have this really funny feeling that I've already seen it somewhere.
hmm. it sounds like you almost want to do the nextstep file.pkg
thing. the nextstep way, of course, can't give hints to the filesystem
because it doesn't use pre-existing directories. if that's what you
mean, i'm not sure how different what you're suggesting is from what i
am with the exception that your way makes it difficult to add packages
to an existing directory hierarchy. e.g., given the following:
a/a
a/b
i can easily add stuff to a/, a/a, and a/b in the following way:
a/.pkg
.pkg/.pkg/fork (parent directory fork)
.pkg/a/fork1
.pkg/a/fork2
.pkg/b/h
.pkg/b/i
if you don't have a "main file" concept, then packages pretty much get
auto-associated with directories. e.g.:
a/.pkg/f
.pkg/g
.pkg/h
a/b
a/c
would bundle f, g, and h together in directory a. that is, your
proposal is identical to doing the following with my setup:
a/.pkg/.pkg/f
.pkg/g
.pkg/h
if we allow forks to themselves be hierarchical, i believe that i get
the rest of what you want. e.g.:
d/.pkg/a/fork1/a
fork2/c
fork2/d/a
d/c
b/forki/a
forki/b
b/forkj
would create a hierarchy of subforks for the "a" and "b" files. if we
add within fork packaging by auto-creating .pkg subdirectories, we can
become arbitrarily silly in terms of how detailed we want to be in
specifying filesystem layout.
having said that, i'm not sure how useful anything beyond a simple
concept of fork hints would be. while database applications might want
to specify the filesystem layout in excruciating detail, i have a
feeling that those applications would end up spending all of their
time in filesystem call overhead land. on the other hand, it could
still be a win if the filesystem hints allow you to open/read/close
more quickly than the corresponding seek/read.
-a
-
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/