Re: [Evolution-hackers] Loading really large E-mails on devices with not enough Vm

[Jeffrey Stedfast <fejj novell com>]

On Sat, 2008-01-26 at 22:12 -0500, Jeffrey Stedfast wrote:
> On Sat, 2008-01-26 at 13:44 +0100, Philip Van Hoof wrote:
> > This is what happens if you try to open a truly large E-mail on a device
> > that has not as much memory available:
> > 
> > Is there something we can do about this? Can we change the MIME parsing
> > algorithm to be less memory demanding for example?
> > 
> > Note that GArray is not really very sparse with memory once you start
> > having a really large array. Perhaps we can in stead change this to a
> > normal pointer array of a fixed size (do we know the size before we
> > start parsing, so that we can allocate an exact size in stead, perhaps?)
> 
> eh, why would you change it to a GPtrArray? It doesn't hold pointers, it
> holds message part content.
> 
> Unfortunately we don't know the size ahead of time.
> 
> I suppose you could use a custom byte array allocator so that you can
> force it to grow by larger chunks or something, dunno.
>
>
> The way GMime handles this is by not loading content into RAM, but 
> that may be harder to do with Camel, especially in the mbox case.

er, I should probably explain this:

- writing the code should be relatively easy to do, but in the mbox
case, the mbox may end up getting expunged or rewritten for some other
reason which may cause problems, not sure how that would work.

I think in Maildir, as long as the fd remains open, the file won't
actually disappear after an unlink() until the fd gets closed, so that
might work out ok assuming you can spare the fd (which might be the
other problem with Evolution?).

Jeff