structured files

Andrew Dunstan (andrewd@writeme.com)
Fri, 9 Jul 1999 10:24:58 -0400


<delurk>

OK, kick me ... why am I getting involved in this? :-)

I'm speaking as a user (albeit moderately clueful) rather than as an app or
kernel developer.

On the KISS principle, I prefer minimalist solutions to problems. I also
dislike the ideas of magic names and magic directories. We do actually know
how to do efficient dynamic structured storage, right? Thank goodness we do,
or file systems wouldn't work. So let's leverage some of that knowledge and
provide a general purpose userland library for manipulating structured files
(Berkeley DB anybody? ;-) The one bit of kernel/fs support that might be
useful is simply a marker that says "this is one of those". Just a one bit
extended attribute, nothing more. Nothing gets broken. App developers should
like it because you take away a lot of the work they otherwise have to do.
You don't need magic names or /etc/magic to know about it.

You could gradually educate cp and friends to know about such things. It
won't happen overnight, but it will happen eventually. If you expect to be
able to do this all in one bang I think you're fooling yourself. OTOH from
day one you could copy, move, ftp, email, use over nfs ... such things and
they could work.

Any solution that requires massive kernel/fs support has this fatal defect:
it's not portable so it won't be used. You'd be crazy as an app developer to
use a purely linux-specific solution. We are not Apple/M$ who can simply say
"We're gonna do it our way and if you don't like it, tough". Linux lives in
a highly heterogenous environment - that is a big part of its attraction.
When I see *bsd and *nix all saying "let's do this in our file systems" I'll
be prepared to reconsider, but I won't be holding my breath waiting for it.

Not only should we look for a solution that could work across OS's, but
across apps. Getting n sets of app developers to support it might be hard
enough. Getting n sets of app developers + m sets of OS developers to
support it sounds like it will be impossible. So it seems to me that we need
a solution that can work independently of OS support, but with the
possibility of mildly enhanced support from the OS.

To those who say "this isn't enough, it doesn't provide the functionality I
want" I would say it probably provides you with 90% of it, so let's try it
and see.

To those who say "let's do absolutely nothing to support this" I would say
that this shouldn't break anything, so let's try it and see :-)

</delurk>

cheers

andrew

-
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/