Corey Nelson wrote: >Are you guys sure? >
I think we have a concensus here, yeah :-D > >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 > Take a look at the event-driven APIs for POIFS and HSSF -- yes, I'm sure that much can be done. Bear in mind, I'm not personally involved in the HDF implementation at the moment, and I'm assuming we can create a similar API ... I could be wrong about that. You have a high regard for the company that invented these file formats ... perhaps you need your medication levels adjusted? :-D > > >>-----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 >>>> >>> >> >
