Bug 337744 - Subscriptions should be configurable before the first sync
Summary: Subscriptions should be configurable before the first sync
Status: RESOLVED UNMAINTAINED
Alias: None
Product: Akonadi
Classification: Frameworks and Libraries
Component: IMAP resource (show other bugs)
Version: GIT (master)
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: Christian Mollekopf
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-07-23 21:53 UTC by Christian Mollekopf
Modified: 2017-01-07 22:01 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Christian Mollekopf 2014-07-23 21:53:37 UTC
Otherwise the sync potentially starts downloading loads of data no one needs.
Comment 1 RJVB 2014-07-25 18:12:36 UTC
Second that.

Here's a good example where the current subscription model is completely useless. I run an imap server on my main workstation; this is the most elegant and appropriate solution I found to be able to archive email from different locations (= computers). When one connects to the imap daemon, it's like connecting over any other file/folder based protocol: one starts in the home directory. So scanning for mailboxes means scanning each and every directory under my home directory, possibly even scanning through the 33GB worth of files that live there (more if imapd follows symlinks which I'm not sure du does). To put this in context: I have about 550MB of email in my archive folder, ~/Mail/Archive.

I just tried this once again. The initial sync took about 15 minutes to grind to a halt, possibly because of memory issues (despite the 8GB of RAM and 10GB of swap).

Of course this example also shows that the current subscription mechanism doesn't really allow to do anything before the 1st sync. After all, it appears to be geared to subscribe to individual mailboxes (i.e. mbox type files on the server). In my case the thing to do would be to subscribe to a *folder* on the server, probably by typing the path into a text field (or else the initial scan should not be exhaustively recursive but proceed level by manually selected level). This action would then subscribe all mailboxes contained in that folder (and ideally do this automatically for each new mailbox that might be created behind akonadi's back, for instance with Apple Mail on a different computer).

What I'm describing is in fact what other email clients call "imap server directory" or "prefix path", a feature which I think is orthogonal to the subscription feature (and indeed often proposed in addition to subscriptions).
Comment 2 Denis Kurz 2016-09-24 20:36:19 UTC
This bug has only been reported for versions older than KDEPIM 4.14 (at most akonadi-1.3). Can anyone tell if this bug still present?

If noone confirms this bug for a recent version of akonadi (part of KDE Applications 15.08 or later), it gets closed in about three months.
Comment 3 Denis Kurz 2017-01-07 22:01:42 UTC
Just as announced in my last comment, I close this bug. If you encounter it again in a recent version (at least 5.0 aka 15.08), please open a new one unless it already exists. Thank you for all your input.