> Alan Cox writes:
>
> > What is the kernel tree. I do believe its a compound document
> > in a directory tree.
>
> The kernel tree is a collection of related documents.
> One could abuse a compound document system to store
> source code, but that would be a lousy idea. Source
> code doesn't have many of the normal document-like
> properties. For example:
>
> There isn't a well-defined and obvious way to print the
> whole thing.
>
> Nobody would think of just cut-and-pasting the whole kernel
> source into another project. Going the other way is also a
> silly concept.
>
> One wouldn't embed a spreadsheet document into the kernel.
> One wouldn't embed a kernel source tree into a spreadsheet.
This seems a very weak argument. Most large documents are a collection of
disparate bits, dragged together to make a cohesive result. It doesn't make
much fundamental difference what that result might be.
How is a large office document produced? It doesn't usually start out as _a_
file. More often several people independently write a few chapters each; an
artist produces some nice diagrams; a researcher generates some spreadsheets
to produce nice graphs of relevant information. Finally its all gathered
together - often with no initial clear idea of how to edit all the bits into
a clean solution. After that the document usually needs regular updates, and
you have a big headache with revision control. That sounds a lot like the way
the kernel comes together.
Take another, and more problematic, example - a CAD database. Currently these
are composed of a whole messy mass of bits, with poor facilities for binding
them into a cohesive package. There could be many file types, for different
vendor's tools. Many files are of objects embedded in others. There could be
whole RDBMSs in the bundle. As yet, nobody has been able to implement a truly
efficient framework for dealing with such a sprawling document, but document
is the appropriate term for it. At the end of the day its the single
definition of the widget that ends up in your hands.
The issue of data collectives is much broader than how to deal with the needs
of an office suite. Changing the nature of the file system is a big step. A
solution narrowly focussed on following Microsoft in the office suite
business would miss a real opportunity to devise a more generic solution to
the needs of collective data bundles.
Steve
-
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/