One more item to throw in the pot:
The "misc executables" thing we have in the kernel now associates an
executable with a file type, which is a common use of resource
forks/EAs. (It uses a config file instead.) If resource forks DID make
it in (which I hope they don't), it would probably be a good idea to
modify this to use them (or at least be able to)...
I still think a user-space
"12345=ObjType=blah:otherdata=moredata:blah=thingy" approach attaching
data to inodes in a per-user file maintained by the bonobo libraries or
whatever is... Well, not exactly "better", but less disgusting. (Okay,
what if your home directory is NFS-mounted on multiple machines. What
about removable media and other transiently mounted filesystems
(network, etc). If we store this data on the filesystem it applies to,
do we really want linux machines littering other people's filesystems
with a dozen copies of per-user information just because they looked at
our filesystem for five seconds? If we store it in the user's home
directory, we need volume ID's to say where these files ARE...)
This is just an evil problem. Can we wait until it's something we
actually need to do before we figure out how we're going to do it?
(I.E. Let the real world usage we'd like to put the solution to work on
have SOME say in determining said solution, and of course let real-world
laziness mitigate out our enthusiasm to make this wonderful abstract
mechanism that can slice bread and change light bulbs and other stuff it
will never actually be asked to do...)
Rob
-
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/
This archive was generated by hypermail 2b29 : Tue Aug 15 2000 - 21:00:29 EST