Re: Balsa and IMAP (again)

[Pawel Salek <pawsa theochem kth se>]

On 2001.07.14 20:48 M . Thielker wrote:
> 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.

I would either have libmutt completely replaced or messed with as little as
possible because this made possible syncing this directory with mutt
possible. But I am open for compromises.

> 
> 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.

Nice GPL-ed, RFC-compatible IMAP access routines would be nice.

> 
> 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.

Train your patience, don't look for fast reward, my teacher used to say
:-).


> 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.

This is actually intentional and very useful for server side message
sorting.I personally find it very useful.

> - 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.

No, only headers are requested. libmutt/imap/message.c:106
I will not comments on tags, though.

> - 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.

Right.

>   Each message is downloaded and in turn APPENDed to the destination
>   mailbox, rather than being copied on the server or simply moved.

There is some code for this in libmutt - but disabled.

> 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.

Would not hurt, but then you loose symmetry between ordinary mailboxes
handled via libmutt, and new IMAP mailboxes. Of course, this hurdle can be
passed.

>  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.

Need some help, ask. There is a good book on this available on
www.gnome.org. libbalsa/address-book.c and derived are good examples.

http://developer.gnome.org/doc/GGAD/

> 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

from libbalsa/mailbox_imap.c, the following functions override
LibBalsaMailbox signal handlers.

    libbalsa_mailbox_class->open_mailbox = libbalsa_mailbox_imap_open;
    libbalsa_mailbox_class->open_mailbox_append =
libbalsa_mailbox_imap_append;
    libbalsa_mailbox_class->close_mailbox = libbalsa_mailbox_imap_close;
    libbalsa_mailbox_class->get_message_stream =
        libbalsa_mailbox_imap_get_message_stream;
    libbalsa_mailbox_class->check = libbalsa_mailbox_imap_check;
    libbalsa_mailbox_class->save_config =
        libbalsa_mailbox_imap_save_config;
    libbalsa_mailbox_class->load_config =
 

> 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.

Right. Creating corresponding mutt-type structures may be painful. But I am
sure, it can be done with little thinking. Or done completely differently.


> 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.

I am not sure if I understand this...

I hope my answers are helpful.

Pawel