Re: parsemail rewrite

From: Daniel Stenberg <Daniel.Stenberg_at_sth.frontec.se_at_hypermail-project.org>
Date: Fri, 23 Apr 1999 16:21:21 +0200 (MET DST)
Message-ID: <Pine.GSO.4.10.9904231617390.17264-100000_at_metal.sth.frontec.se>


On Fri, 23 Apr 1999, John Finlay wrote:

> Just to follow up on my previous message. My thinking is that the
> strategy of parsemail is to extract each email message as a whole
> breaking it into header and body sections but not doing further
> processing of the body until later. This is simple and straightforward.

I agree that it sounds simple and straightforward eoungh, only a tad too much memory consuming for my taste.

> During the printing of the messages, the message decoding and MIME
> decoding of the message bodies would be done (though this can be done any
> time after it is decided to save the message.

Consider the case when reading a mail with 10MB mime attachment. I say it needs to be stored while read, while your version would alloc memory for this beast and keep it in memory for a while until later. What if you read a mailbox with a 100 of such attachments...?

> I'm not sure I completely understand the handling of multipart messages
> especially when they are recursive (e.g. multipart/digest). Is it the
> intention to handle these fully i.e. multipart messages inside multipart
> messages? the comments seem to recognize the problem but it's unclear to
> me whether full recursion has been implemented.

I don't think multipart/digest is fully supported, no.

-- 
             Daniel Stenberg - http://www.fts.frontec.se/~dast
   ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol
Received on Fri 23 Apr 1999 04:20:12 PM GMT

This archive was generated by hypermail 2.3.0 : Sat 13 Mar 2010 03:46:11 AM GMT GMT