Balsa and IMAP (again)

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

Hi,

 I am currently working on another issue, this regards mailbox checking.
After fixing the flags problem and thereby getting into libmutt IMAP code I
found, that there is some very inefficient communication code in there.
Especially some server features relating to mailbox checking aren't being
used to the extent possible and _needed_.

I would like to have the message counts of all mailboxes, but at least all
IMAP mailboxes displayed next to the folder names at startup. The way to
implement this is quite obvious, but it does involve more than just simple
changes to libmutt.

Before I get into this, I would like to know which, if any, projects are
underway to change the handling of IMAP and/or augment/replace libmutt. I
had myself started doing a new library for IMAP and mbox, but had soon found
out that there's more to that than meets the eye.

In view of the long-term nature of such a project and the lack of immediate
benefits for Balsa, I have placed my efforts on a back burner.

Mainly, the problems with IMAP, as I perceive them, are these:
- When checking for new mail, a STATUS request is issued for _every_
  folder, unless it's restricted to the INBOX by my patch. This happens
  on every mailcheck, but not all usable and needed values are retrieved.
- When opening a mailbox, Balsa is extremely slow, I don't know why that
  is the case, yet, but I have a dire suspicion it could be because
  each message is requested from the open mailbox in full, not just
  the header. Also, tags are not used efficiently.
- Since all message handling is done in libmutt, but all coordination 
  is in Balsa code that should, ideally, be unaware of the underlying
  storage medium, no optimization takes place on copy or move operations.
  Each message is downloaded and in turn APPENDed to the destination
  mailbox, rather than being copied on the server or simply moved.
- Some people have added rudimentary support for listing IMAP trees in
  Balsa, but I am still missing a folder type that can contain messages
  as well as subfolders. There should really be no distinction between
  an IMAP folder and an IMAP mailbox in the mailbox tree. At least the
  server doesn't make one, why should we? In order to fully utilize
  such a folder, I now must enter it into the tree twice: once as an
  IMAP mailbox and once as an IMAP folder. The former allows me to see
  the messages in the folder while the latter shows the subfolders and
  the messages contained in them. This is pointless and appears to be
  a design inherited from mbox/maildir days. AM I right when I assume
  that folders were once abstract data items present in Balsa's config
  only, but not actually existing on disk?

These issues need to be addressed, and tackling one means to d someting
about all of them. Really the best thing would be to take IMAP handling
away from libmutt, but I wouldn't know where to start looking for the
relevant libmutt calls in Balsa code. Additionally, I have yet not fully
understood the concept of classes without c++, as used in gtk+. I know
how to use them, but don't know how to create them or make major changes
to one.

I think that LibBalsaMailboxImap needs to be redone, but I don't know
which of it's methods are inherited from LibBalsaMailboxRemote or 
LibBalsaMailbox, and are therefore dependent on libmutt code. Just
isolating a function, redoing it and trying it out seems to be near
impossible in this situation, because when I implement a function
outside of libmutt, mutt's internal data will no longer reflect the
results of the function's activity. So, other functions will probably
fail in completely unrelated ways and it would be hell to track down
something like that.

So, I would really appreciate some help. It would be nice to have a
template mailbox class, one that does have it's place in the classes chain,
but doesn't inherit any methos that may call libmutt.

Well, enough of this rambling on...

Melanie