[Maf] bugs and questions :-)

[Molle Bestefich]

Christopher Ottley wrote:
> Molle Bestefich wrote:
> 
>> 1. When MAF is installed, Mozilla correctly opens MHTML files named
>> "xxx.mht".  Files named ".mhtml" does not open however, one has to open
>> IE or MS-WORD (or rename the file, if you know what's wrong..)
> requests planned to implement. Just so I don't forget, please file a bug
> report in bugzilla on mozdev if you really want this.

Added to bugzilla.

FYI, you maff files, when fed through an 8.3 filesystem, becomes
MS-ACCESS Forms, which have their extension hidden by default in
explorer, so no easy way of renaming them back to maff.... gah.

>> 2. When loading an archive in one browser window, all other windows
>> are frozen.
>>
>>
> The decoding is done in Javascript, and although fast, can take a bit of
> time to do. Technically they're not frozen, just really slow. (Slow
> enough to look frozen). The engine is shared amongst all the windows, so
> if it's taken up decoding it has little time to draw / repaint.

Hm.. Still, it's not nice..
Is it possible to check if there's something else that needs to be
done and sleep for a few seconds if that seems to be the case?  (If
focus is lost for instance?)  Or perhaps just sleep 50 msec now and
then?

>> 3. The correct name for these files is "MHTML Document", not "MHT
>> Archive" - check 'File Types' under 'Folder Options' in Windows.
>>
>>
> Pot-aye-toe pot-ah-toe. Heh.

:-).
I've added it to bugzilla just to annoy you.
Bwahaha!

>> 4. Loading MHTML archives is quite slow.. Why? Could it be profiled
>> and optimized?
>>
> The algorithm to do most of the decoding is O(n). To meet the MHT
> standard for decoding however I had to implement a O(3n*m) algorithm. I
> benchmarked it and that's the thing that takes most of the processing
> time. I had originally started with a much more efficient algorithm for
> that in mind, but Mozilla security components stopped me in my tracks at
> the time. As a quick workaround for 0.5.0, MAF MHTs don't actually need
> the algorithm because MAF doesn't encode using CIDs or nested mime
> parts, and so in CVS I have a check that skips running the algorithm if
> it's a MAF MHT archive. The effect is that the decoding is faster if
> it's a MAF MHT, but the same speed if it's not.

Ok.. The original does have a very big advantage in that it's a de
facto standard and other users can open it in Internet Explorer,
MS-WORD and such.  So I'm sticking with that, albeit the slow speed
:-/.

>> 5. Why the new archive format? What advantages does it provide over
>> MHTML or .mhtml.gz?
>>
> Well, first off it's a true archive, so you can easily modify it outside
> of Mozilla.

Ok.  The modifications I do are limited to snipping out (most, if not
all) JavaScript and perhaps banners from downloaded pages, which is
also easily done in MHTML archives.

> Another advantage is that you can easily place multiple
> pages in the archive.  MHTML is technically an encoding that transforms
> binary and text files to encoded text so .mhtml.gz would first have to
> decompress and then decode the document to view it. With .maff all you
> have to do is decompress. Simpler usually means faster and faster is
> usually better. :) .

Hm, fair nuff, I can see how not having to decode saves a bunch of
time, especially since it's done in JS!

Thanks for the enlightenment :-)