[Akonadi] [Bug 335795] New: IMAP namespace support is incomplete/insufficient on large imap accounts

[RJVB]

https://bugs.kde.org/show_bug.cgi?id=335795

            Bug ID: 335795
           Summary: IMAP namespace support is incomplete/insufficient on
                    large imap accounts
    Classification: Unclassified
           Product: Akonadi
           Version: 4.13
          Platform: unspecified
                OS: All
            Status: UNCONFIRMED
          Severity: grave
          Priority: NOR
         Component: IMAP resource
          Assignee: chrigi_1 at fastmail.fm
          Reporter: rjvbertin at gmail.com
                CC: kdepim-bugs at kde.org, vkrause at kde.org

I run an imap server on my main workstation, allowing me to archive email no
matter from what computer I'm doing that. Those archives live under
~/Mail/Archives, and an imap client not ignoring everything above that path
will spend a very long time indexing ~ (I had to kill and delete the resource
when it hogged the whole computer after I let it run for about 2h).

I've skimmed through a few discussions on kmail's approach to the "imap prefix
path" most email readers support, and while I tend to agree that if namespaces
are the standards compliant way to do things they should be used, I also think
the implementation isn't without flaws.

Let's ignore the fact that the current imap configuration dialog doesn't even
mention namespaces (presumably replaced by server-side subscriptions?). The
real gripe I have is that I apparently have to let the imap process index the
full server-side contents before I can point it to the appropriate root folder
(Mail/Archives). And it's not just an omission in the GUI: I tried simulating
the required actions with a small imap account, and observed that apparently
all mailboxes (folders) under the root are listed explicitly in the
configuration file, rather than only the root folder. Which in my book is not
using a namespace as any addition (new folder) will have to be added manually
to the selection (requiring another lengthy indexing step).

I'd suggest reinstating a simple "prefix path" feature that can be specified (=
typed in) even before the first connection to a new imap account. It's only a
single text entry field, and internally it could perfectly well be translated
into the appropriate namespace magic.

Reproducible: Always

Steps to Reproduce:
1. set up an imap server on a workstation
2. Use Thunderbird, Apple's Mail.app, sylpheed, pine, just about any MUA to set
up an email archive on that imap server, connecting with your work/home account
on that, for instance under Mail/Archives (= ~/Mail/Archives)
3. Define an akonadi imap resource pointing to that same IMAP server, using the
same login credentials
4. Sit back and wait ...
Actual Results:  
A synchronisation step will be triggered that can take hours to complete if the
user home directory (the "~" namespace) contains a large amount of files and
folders, of which only 1 is relevant for the imap resource (Mail/Archives, and
the mbox files contained therein).

Expected Results:  
Given additional configuration options, either to specify a path prefix or to
alter the namespace queried, or both (as Thunderbird does). 

I don't have direct experience using imap namespaces, but if they don't allow
to specify the path to where the mailboxes are (to be) stored, an additional
mechanism should be implemented. Again, just about any other email client
allows to do that. Following standards nice, but it should not become a case of
form over function.

I'm marking this bug as "grave", because it requires serious workarounds if one
is obliged to work with an imap server as outlined above.

-- 
You are receiving this mail because:
You are on the CC list for the bug.