vm-list-imap-folders slow

Other possibilities:

- Use a subscription list, to select the folders to be listed.

- Try the EXAMINE command on the server.

Konrad Hinsen:

 > IMAP provides a "LIST" command which is required to be fast but doesn't give
 > the status of the folders, and a separate "STATUS" command which is allowed
 > to be slow and has to be queried individually for each folder. I would
 > expect that many IMAP implementations take it to be a license for being as
 > slow as possible.

I doubt it's a server problem, because Mulberry scans my 395 mailboxes
much faster then vm-list-imap-folders. Another candidate for
explaining the difference is threads: Mulberry runs multiple threads
that do IMAP requests in parallel.

> I doubt it's a server problem, because Mulberry scans my 395 mailboxes
> much faster then vm-list-imap-folders. Another candidate for
> explaining the difference is threads: Mulberry runs multiple threads
> that do IMAP requests in parallel.

That kind of proves my point. Because IMAP servers do such a bad job,
Mulberry is having to beat them into shape by issuing multiple parallel
requests. Of course, on an overloaded IMAP server, that would achieve
nothing.

If you have a way of finding out what requests Mulberry is issuing, I can
try and duplicate that. I have had it in my mind to try out the EXAMINE
command instead of the STATUS command. It is counter-intuitive for EXAMINE
to be faster than STATUS, but who knows?

> My personal workaround is a specialized version of
> vm-list-imap-folders that checks only the folders to which messages
> can be delivered. That's only 20 out of 395, and speed is no longer a
> problem. Which points of course to the strong point of VM: it's a
> fully scriptable mail reader. Even if something is not perfect, you
> can at least work around it.

I might also try and implement a "subscription" feature so that we don't
have to look at all the folders.

Cheers,
Uday