[Kde-pim] Synchronizing local subscriptions with the IMAP serverside subscription state

Tue May 13 19:14:48 BST 2014

On Tuesday 13 May 2014 10:45:13 Christian Mollekopf wrote:
> On Monday 12 May 2014 20.24:09 Ingo Klöcker wrote:
> > On Monday 12 May 2014 16:33:12 Christian Mollekopf wrote:
> > > Hey,
> > > 
> > > I want the IMAP resource to synchronize the server-side
> > > subscriptions
> > > with the local subscription state in akonadi.
> > 
> > I've read your mail and techbase, but I still don't understand what
> > you mean by "synchronize the server-side subscriptions with the
> > local subscription state". I do understand that you don't mean that
> > server- side subscriptions and local subscriptions are kept
> > identical (which is what I understand if somebody says
> > 'synchronize').
> 
> I actually mean that they are kept identical (in-sync) =)
> At least if you enable sever-side subscriptions in the imap resource.
> If you don't we ignore server-side subscriptions and you can use
> local subscriptions only. But lest assume you have them enabled for
> the rest of the discussion.

Okay.

> > Please explain what you mean with a few examples. What happens if I
> > add a folder to my server-side subscriptions? What happens if I add
> > a folder to my local subscriptions? What happens if I create a new
> > folder on the server resp. locally? What happens if I remove a
> > folder from either subscriptions?
> 
> I essentially want to remove the server-side/local subscription
> distinction. Either you are subscribed to a folder or you are not,
> and if the IMAP resource has server-side subscriptions enabled it
> mirrors that subscription state to the server as an indication that
> you're interested in this folder, no matter what device your
> connecting to the server (so server-side subscription is simply used
> to synchronize your subscription state).

I think this "no matter what device you are connecting to the server" 
assumption is were we disagree. For use cases see below.

> So that's the basic change I want to make, it reduces the complexity
> and IMO achieves what I would have expected from the system anyways
> (I never understood what I should do with local subscriptions).

IIRC then local subscriptions were introduced in KMail 1 to make it 
possible to access some IMAP folders of an IMAP account via a KMail 1 
online IMAP account (without caching of the message bodies) and to 
access other folder (e.g. the Kolab folders) of the same IMAP account 
via a KMail 1 disconnected IMAP account (with caching of the message 
bodies).

With KMail 2 this use case doesn't require the "two separate IMAP 
accounts"-hack anymore (because the caching can be configured per 
folder).

However, there are other use cases. For example, I could use server-side 
subscription as a kind of first-level filter to filter out all folders 
I'm absolutely not interested in (e.g. if there are a lot of shared 
folders which are visible for everyone; think a public IMAP server 
hosting the mailing list archives of all KDE mailing lists). And I could 
use local subscription as second-level filter to only have the really 
important folders available on my limited-storage-capacity-and-limited-
screen-estate mobile device while I want to have all server-side 
subscribed folder available on my almost-unlimited-storage-capacity-and-
huge-screen-estate desktop machine.

Another use case where two-level filtering would be helpful is a 
scenario with a limited-bandwidth machine (e.g. at home) vs. a high-
bandwidth machine (e.g. at work).

> However, it also enables me to do one more thing. I can always
> synchronize the complete folder list (not the content),

Even synchronizing only the folder list could saturate the storage of a 
mobile device. Just think of archive folders.

> ignoring the
> subscription state, and then use the subscription state for what I
> want offline (in a disconnected-IMAP scenario).

We have per-folder caching options for configuring which folders you 
want to have available offline.

> By default all
> non-subscribed collections will be hidden, since not subscribed to
> locally.

and not subscribed to server-side I assume (since "you want to remove 
the server-side/local subscription distinction").

> It's then fairly easy to give the user the possibility to
> say "I'm not normally subscribed to that shared folder, but let me
> just take a look now since I have internet.". We can simply
> synchronize the folder quickly in online-imap style, without changing
> any subscriptions. And that would IMO make Kontact quite a bit more
> awesome.

I'm not sure this use case is a good enough reason to always synchronize 
all folders regardless of their subscription state. I think a solution 
which synchronizes just this folder or, even better, just the newest 
messages of this folder on demand probably via a temporary throw-away-
after-use Akonadi resource might be better.

If you regularly want to have a peek at a certain folder (which would be 
an argument against using a temporary Akonadi resource) then you should 
probably subscribe to this folder.

Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20140513/b7cf857d/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/