Are you guys sure? Just kidding. ;) Thanks guys.
What about just the reading part? Could one read page 935 without loading the whole file into memory? That doesn't seem like it should be hard to do... just read some sort of index and skip to the part you need. Surely they got that much right. Corey > -----Original Message----- > From: Marc [SMTP:[EMAIL PROTECTED]] > Sent: Monday, March 04, 2002 7:15 PM > To: [EMAIL PROTECTED] > Subject: Re: Fast loading and saving? > > acoliver wrote: > > >>On Mon, 4 Mar 2002 15:48:00 -0700 Corey Nelson > <[EMAIL PROTECTED]> > >> > >wrote. > > > >>I've been told that one of the benefits (perhaps the only) of using OLE2 > CD > >>format is that you don't have to load or save the entire file when you > just > >>want read or edit a small part of it. If you had War and Peace in a Word > >>Document and you wanted to fix a typo on page 935 it wouldn't take > forever > >>to open the file or save your changes. > >> > >>Question 1) Is this true? > >> > > > >NO! Thats totally bogus! OLE 2 CDF is formatted as such to make this > >impossible (downstream pointers to upstream things and vice versa). > > > >Marc, would you like to expand on that? > > > > Ahem. Sure, Andy. > > Basically, OLE 2 CDF is similar to an old fashioned file system (how > similar? similar enough that it would benefit from a defragmenter tool > ...). The only way for an application to perform the efficient editing > you speak of, it would need to directly manipulate the file system. > Imagine an application that took over the writing of individual sectors > "for efficiency sake" ... that's what an application would have to do to > achieve the efficiency you speak of -- it would have to manipulate the > block chains to do that. > > My experience with very large Word documents (~50-60 pages) indicates > that this efficiency does not exist. Said documents are slow to load and > slow to write. > > > > > > >>Question 2) If so, is this still true if I'm using POIFS to read and > write > >>the file? > >> > > > >Nope, we read it rather efficiently if I might say so, but the format > SUCKS > >and prevents this. > > > > We read it with as much efficiency as we can bring to bear, given the > inefficient file format. We write it out as efficiently as possible, > more efficiently than other *cough* applications seem to do (our output > requires no defragmentation). > > > > > > ><rant> > > > <snip/> > > ></rant> > > > >OLE 2 Compound Document format is NOTHING more then a completely > convoluted > >archive format. Use ZIP with no compression and you achieve the same > >thing.. The only thing OLE 2 CDF buys you is that it slighly obfuscates > >(poorly) the format of your file from platforms without a Java 2 JVM > (since > >POI unobfuscates it ;-) )... > > > >So why would we put ourselves through this: Its fun! Intellectually > >challenging! (It shouldn't be to just read a file format, but it IS!) > And > >we get to spit in the eye of closed file formats everywhere! > > > >>Thanks for reading. > >> > > > >No problem.. I needed to unwind for the day ;-) > > > >-Andy > > > >PS to understand what I think of the OLE 2 Compound Document Format, XLS > >format or DOC format -- count all of the times the word SUCKS appears in > >this email and multiply it by 10 to the 99th power and you will have some > >vague idea on what I think of the formats and the morons who designed > them. > >:-) -- But unmangling them into nice object models is really fun! > >(seriously we do this for the intellectual challenge because all of the > work > >people pay us for is to technically easy!) > > > > > >>Corey > >> > > > > > >
