Messages in this thread | | | Date | Wed, 7 Jul 1999 06:39:38 -0400 | From | Raul Miller <> | Subject | Re: [RFC] File flags handling - proposal for API. |
| |
Let me get this straight: we're talking about writing a *new copy* of a compound document, right? [Leaving the old copy as a backup.] [Or maybe you're trying to say that backup copies of a document are stupid?]
And the claim is that introducing "file system internal to the file" is somehow going to make that faster.
And the claim is that using the existing file support is *bad* because it will confuse the newbie?
For this model to even vaugely make sense, you're talking about internal hard links from one document component element *into* another document. And writing an application smart enough to know how to generate proper backups vs. proper updated documents taking advantage of this complex file concept.
[But what we're really talking about is making MS-Word run faster, and probably about making Samba run faster, and for that we should be focussing on WINE and Samba and maybe on kernel tweaks based on careful analysis of WINE/Samba performance tests.]
If you're not talking about specifically enhancing MS-Word, and all you're concerned about is write latency, note that it's relatively trivial to fork and save in the background. It might be necessary to enhance the kernel to reserve a certain amount of disk space (or fail) right away, but that sounds a lot simpler than moving MS-Word semantics into the kernel.
But maybe I'm just stupid.
-- Raul
- 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/
| |