> 1. If you get the design of something wrong, it's a lot easier to change or
> unwire it if it lives in an API library than if it lives in the kernel.
> We *will* get the metadata design wrong the first time. Let's do our
> prototyping in user space, guys, to hold down the number of potentially
> destructive interactions.
How about "let's do it in user space, period"? Or better yet, "make your
programs include the same functionality without using 'metadata'"? :)
This war has already been by the GNOME mailing lists about ten million
times, and nobody ever comes up with a perfect solution. I suggest that it
is because there isn't one!
"Do it as a directory with files in it (like NeXT)"
- Not transparent
- Not backwards compatible
"Do it in the kernel as part of the FS"
- Not portable
- Unneeded bloat
- the high ratio of possible userland to kernel
solutions suggests that the best way to do it is probably in
userland.
"Do it as an LD_PRELOAD"
- Will slow down all programs whether they need it or not
- Hackish and unreliable (i.e. programs can segv
when LD_PRELOADing just a replacement time() function)
"Maintain a database of filename -> metadata mappings"
- Not transparent
- Storage locations. Storing one fork of a file in
one place and another fork in another place would
cause problems for inter-user database sharing and
sane quota maintainance
"Use the netatalk approach" (dot directories with mirror files in them)
+ At least this has been widely tested & used
- Not transparent
Did I forgot to bash any other approaches? ;-)
No such thing as free software design lunch,
-- Elliot
Progress (n.): The process through which Usenet has evolved from smart
people in front of dumb terminals to dumb people in front of smart
terminals. -- obs@burnout.demon.co.uk
-
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.altern.org/andrebalsa/doc/lkml-faq.html