Re: For 1.5.9: attachment counting for index display
* On 2005.09.12, in <20050913022948.GC1502@xxxxxxxxxxxxxxxxxxx>,
* "Brendan Cully" <brendan@xxxxxxxxxx> wrote:
>
> I like the idea too. I just read the patch, and it seems sounds, but
> maybe somewhat overengineered? Does it really need attach-allow et al,
> or can we just have some "sensible defaults" eg ignore inline
> parts and pgp attachments. Actually the defaults in the patch look
> pretty reasonable, I'd be tempted to just hard-code them to save
> config bandwidth.
Originally it wasn't configurable, just had sensible defaults. While
making some changes to those sensibilities in a later update of the
patch, I thought some might appreciate the ability to select those
defaults for themselves. :) And indeed, I've occasionally wanted to
tweak those settings to accomodate specific kinds of searches/limits
where certain bizarre sending mailers are involved.
I prefer keeping the attach-allow etc, but would agree with hard-coding
the defaults instead of putting them in the default config file. I've
just tried to minimize impact, since my largest goal is just to stop
maintaining the patch by getting it into CVS. :)
> > Thinking about it some more: would it make sense to alter this patch
> > somewhat, and to:
> >
> > - not automatically parse the tree for Maildir and IMAP mailfolders,
> > but display a "?" (or something like that, or nothing at all)
> > instead?
> >
> > - cache the attachment information for these types of folders?
>
> I think it's probably worthwhile to either cache the number or simply
> not throw out the parsed content, depending on the memory usage of the
> latter.
Tossing out the parsed content was a concession to concerns about
performance. keeping the parsed content would accelerate other
operations, but I'm not sure it's really worth it. I do think it would
be wise to cache (in memory, in the envelope structure) the results
of the parse, though. I assume that nobody meant disk caching, just
because I mentioned in-core caching in the previous message, but that
would be interesting, too.
I stand by to help if it will get into HEAD. :)
--
-D. dgc@xxxxxxxxxxxx NSIT University of Chicago