Re: PATCH: IMAP flag handling and new mail notification

["M . Thielker" <balsa t-data com>]

Hi Pawel,

On 2001.07.16 23:19 Pawel Salek wrote:

> Concerning balsa-imapcounts.patch, I could not apply it, I got some
> conflicts in src/main-window.c Anyway, I have looked at the code and I
> wondered if it would not be better to look at OPTIMAPPASSIVE libmutt
> option: the code seem to open IMAP connection even if not explicitely
> asked
> to (but I can be wrong). This might be annoying for some users.
> 
Until I get done with new IMAP access routines, we have to live with
libmutt. Unfortunately, all avenues I have explored using OPTIMAPPASSIVE
lead to either extensive, unnecessary changes in libbalsa that would have to
be reversed once decent IMAP routines are available or would require to read
all meilboxes to insure data integrity.
I made this patch for one, and only one purpose: I have IMAP folders
containing project relevant email. A project can be considered idle, nothing
to do on it, when there's no email in the folder, because processed request
are moved to other folders. Sometimes these project folders can become quite
large (about 5000 msgs). It takes forever to read all of them, I needed a
way to see how much remains to be done on each project without opening the
mailboxes.
Current IMAP code is not meant for offline operation, an IMAP server
connection is required at all times. Because of this, I dod not consider it
worth an option in prefs. Could be done quite easily, though. If you use
IMAP folders with Balsa, you can always miss a folder and click one that is
IMAP, and it will be opened without further dialog. Therefore, anyone who
uses Balsa with IMAP folders is prepared to connect to the IMAP server
anyway. Since I can, from there premises, safely assume that Balsa will not
be used when no connection is possible or desired, I did it this way.
As for the implementation, the point is to _not_ have too much special case
handling of IMAP strewn all about in libbalsa, because when libIMAP is done,
it will all have to be pulled out again.
The concept I have planned for libIMAP includes synchronous and asynchronous
request methods for messages and other server information, automatic
multiple connection handling, assignment and teardown as well as a local
cache of IMAP messages and transparent, automatic update of the local store.
I expect a speed increase of about 600% on a LAN connection, more on a WAN
or dialup.
This is an ambitious project and will take a while, so I made this patch to
fix the most glaring (in my opionion) drawback to IMAP use in Balsa:
Inability to see the message counts of IMAP mailboxes without opening them
first.
If you want a checkbox in prefs, I'll put one in, no problem. There will be
another fix forthcoming anyway, As I posted to the list a few days ago, IMAP
folder message counts are not updated properly on multiple message copy/move
ops.
I'll look into this when I get time.

Cheers,

Melanie
(I really should write less text and more code :) )