Why use Open Source when Microsoft products are so cheap... 10019
In comp.os.linux.advocacy, Kelsey Bjarnason wrote on Sun, 07 Aug 2005 11:00:08 GMT
Good points. I'll admit were I to design a system similar to MS's Word in documentation format, I'd use a lot of self-relative pointers, and maybe an indicator with each pointer as to what file to refer to in an index somewhere (file #0 would be the document itself).
Why use Open Source when Microsoft products are so cheap... 10020
snips For that kind of money, they should damn well be learning how to cope with life, rather than simply buttume it stays...
The header would be at the top of the file and the "load" would be little more than mapping the file.
Actual loading, of course, would occur as the user is paging through the documentation; the kernel would see an invalid page address, figure out where it is on disk, and read it into memory, throwing out another page as required in the more or less usual fashion. Whether users would tolerate this is an interesting question. (A "force-load" option is possible, I suppose, but the user has to have sufficient RAM for it to work properly.)
If the loaded document refers to another document, the load might be deferred until needed; the reference would be such that the layout would not require the document referenced. (For example, if a page refers to a picture, the page would be required to specify the size of the picture and the software would autoscale if the sizes are different.
In theory such a system would open almost instantaneously; the main issue is how fast can one do a stat()-open()-mmap() combination. (I'd have to see regarding mmap()ping over NFS, though. If one cannot one can still open it, and seek as required. If one cannot seek, well, one can keep the pages in memory as one moves forward through the file.)
Homeland Insecurity 10022
Kind of getting off track here a little bit. The original Carnivore thing didn't really work so well, and all that's...
The reason for the index, of course, is that one can then put the changes in a temporary file (that might be file #1). When saved, the new file, which would be constructed by running through the entire document, would replace the old one after construction; if there's an I-O error during construction the save can be safely aborted, at least in theory.
A variant would represent the "pointer" as an ASCII string instead of a binary 4- or 8-byte value; the value would still be self-relative.
XML would be ideal except that no current parser can support in an elegant fashion the modification of a partially-parsed document.
I'm definitely going to have to play with this at some point. ;-)
-- It's still legal to go .sigless.