Re: base64 bug handling \r characters

I think we can fake out the logic by maintaining the "data structure"
that describes the message.  It is loosely described in mime.tcl,
and there is a field for the name of the temp file that stores the
message part.  I'll bet you are referring to the implied relationship
between the message part nesting level and the temporary file name,
but I'm pretty sure mhstore does something similar.  So, I'd keep
the fastpath code in mime.tcl for straight text display,
but then for multiparts just exec mhstore (need to figure out how
to get it to put its temp files where exmh wants them) and then set
up the mime() array with information about all the parts.

>>>[email protected] said:
 > On Fri, 24 Sep 2004 16:40:15 PDT Brent Welch wrote:
 > >
 > >Yes - the mhstore function probably has most of what we need,
 > >and could be used to replace a bunch of the parsing code.
 > >I haven't quite found any time to pursue that, but it is promising.
 > >
 > >As background, right now Exmh parses mime messages by reading them
 > >and chopping them into parts, which it stores in a temp directory.
 > >As it does that, it decodes according to the content-transfer-encoding.
 > >That's pretty much exactly what mhstore does, too.
 > >
 > 
 > That's the one I had in mind too. At least on my old computer, 
 > whenever I hit a 10MB mail with say 5 attachments the displaying of 
 > it takes quite some time. mhstore completes in a second or so...
 > 
 > I recall looking into this one once, but the logic which hinged on 
 > the tmp filestucture for the parts seemed to be all over the place/
 > too much/whatever for the limited time I had available at the time. 
 > Maybe it's time to have another go at it. 
 > 
 > /Anders
 > 

--
Brent Welch
Software Architect, Panasas Inc
Delivering the premier storage system for scalable Linux clusters

www.panasas.com
[email protected]