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

[Christian Mollekopf]

On Tuesday 13 May 2014 20.14:48 Ingo Klöcker wrote:

Hey Ingo,

Thanks for your input!

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

Makes sense.

I meanwhile thought a bit more about this and I'll revise my proposal to also 
cater those usecases.

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

I honestly doubt that. Even if you have access to a million folders, storage 
space shouldn't be the problem.

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

Right.

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

I don't think a temporary throwaway resource is the way to go, but I'll revise 
my proposal so your use-cases are covered as well.

Cheers,
Christian

_______________________________________________
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/