On Mon, Jan 22, 2001 at 01:10:46PM +0000, Dave Pearson wrote:
> On Mon, Jan 22, 2001 at 01:34:03PM +0100, Heinrich Langos wrote:
>
> > On Sun, Jan 21, 2001 at 08:07:58PM +0000, Dave Pearson wrote:
> [...]
> > it's not only me who wants mutt to behave that way, i guess. if it was not
> > the intention to make mutt detect new mail it would say "... the main menu
> > status bar displays how any of these folders have been modified since they
> > where accessed by some programm." ;-)
>
> I agree that this can be viewed as a documentation problem.
In your opinion the documentation is wrong and should be changed to
something like the above? Well, ok then I really misunderstood you
all the time and I misunderstood the documentation. I'm sorry I
wasted your time.
I guess continuing this discussion will not get us anywhere then.
Anyway I will continue this mail since I have some ideas that may
improve the performance in case somebody, maybe me, wants to fix
the non-existing problem :-)
Dave, you may stop reading. The rest will only bother you and further
waste your time.
> > > The problem with such a scan is that it could take ages. I've got a lot of
> > > mailboxes, some of which can be huge.
> >
> > it only scans mailboxes that are marked as incoming mailboxes.
>
> That's why I said "mailboxes".
ok ok .. just wanted to make sure we talk about the same thing.
i guess most users don't have huge mailboxes since mbox-hooks are a
such a nice way to move older mail out of mailboxes after some time.
anyway...
> > so it would do the same thing it does, when opening that mbox. only to all
> > of them at once... ok ok .. that would be some overhead.
>
> That could and would be a *lot* of overhead.
realy? lets see...
and keep in mind that this does not need to be mutts standard way to
detect new mail. just the one it uses when you TAB TAB. or start mutt
with -y.
when you save modification date, filesize, known amount of new mail,
and an md5sum they will only be generated once for each mailbox. so
assuming that you don't add mailboxes on an hourly base I will forget
about that one-time load.
if a change occures (detecting may be done by modification time,
filesize, md5sum (sorted accending by paranoia)) and the filesize
increases you could assume that there is new mail (if it decreased you
could mark that mailbox as "C" for changed or something like that and
stop here).
jump to the previously know end of the file and scan how may new mails
arrived. that shouldn't be too much of a burden for a system. since
mails usually don't arrive in large batches. (i know, fetchmail users
will hate me.)
to prevent errors due to other programms, maliciously changing your
mailboxes and increasing its size, you could check for that.
depending on your level of paranoia you could do anything.
from
A) checking if a new mail starts exactly where it is supposed to start
(at the previously know file-end, which you do anyway by starting
parsingthere)
to
Z) checksumming the mailbox up to the last known
fileend and comparing with the saved checksum.
assuming that increased size usually means that new mail has been
added the overhead would be very small.
if you still think it is too much overhead go for this one:
cache the information that you gathered during those scans to skip the
initial scan that mutt does when you enter a folder.
this will reduce the overhead to almost zero. only if you don't read
the folder that has new mail you will have wasted time. but why do you
get that mail at all if you dont read it ? :-)
for maildir environments the solution seems straightforward.
what about imap? i don't have a clue. could somebody enlighten me?
-heinrich
--
Heinrich Langos <[EMAIL PROTECTED]>
pgp: http://wh9.tu-dresden.de/~heinrich/pub_pgp_key.asc
_________________________________________________________________
|o| The reason we come up with new versions is not to fix bugs. |o|
|o| It's absolutely not. It's the stupidest reason to buy a new |o|
|o| version I ever heard. -- Bill Gates, Microsoft Corporation |o|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
