Plasma hangs, could not log in
Kevin Krammer
kevin.krammer at gmx.at
Wed Jul 20 22:53:03 BST 2011
On Wednesday, 2011-07-20, Anne Wilson wrote:
> On Wednesday, July 20, 2011 08:07:31 PM Kevin Krammer wrote:
> > On Wednesday, 2011-07-20, Anne Wilson wrote:
> > > Many of those things have already been addressed. Yes, any database
> > > that attempts to index everything is going to be big. The KMail
> > > issue, though, I consider to be more serious. I take it that you are
> > > using the experimental KMail2? I understand that IMAP and DIMAP have
> > > been merged, and I assume that that means DIMAP (downloaded) in every
> > > case. I'm not too happy about that myself.
> >
> > IMAP and DIMAP have only been merged in the sense that KMail no longer
> > contains any kinds differences between the two account types, nor does
> > the IMAP resource as the new IMAP server accessor.
> > It does not mean that there is no "online" IMAP anymore, that still
> > exists.
> >
> > Local caching of mails is now actually doable on a much more fine grained
> > level, e.g. on per-folder than on per-account basis.
> > As far as I know there is just no folder level UI for that yet, so "DIMAP
> > account" still cache all folders and "IMAP accounts" cache none.
>
> Kevin, you're doing a wonderful job of trying to explain everything to
> us,but I have to admit, I'm still confused.
Understandably, neither current nor new situation are simple.
In KMail 1 terms, IMAP and DIMAP are two entirely different forms of accounts,
handled in a very different way inside KMail's code.
In the new system, any folder is basically treated equally, i.e. each folder
has some Akonadi internal data attached to it that tells Akonadi how to deal
with the folder's contents.
This information can tell Akonadi to keep certain parts of mails cached, or
whether to permanently keep some but discard others after some time.
Mapping KMail 1 behavior onto the new system would basically mean:
- IMAP: keep headers permanently, forget mesage bodies as soon as possible
- DIMAP: keep full emails permanently
The chosen behavior is slighlty different:
- "IMAP": keep headers permanently, forget message bodies after 60 minutes
- "DIMAP": keep full emails permanenty.
So same behavior for "DIMAP", almost same behavior for "IMAP" (switching back
and forth between several messages will be slow at first but then happen at
local speed unless time between two accesses on the same message exceeds cache
timeout).
The goal of course is to make this more accessible to the users, e.g.
allowing them to keep certain folders fully available locally like in an old
DIMAP account but not needing to have space for all of them.
As I said I am not sure yet whether any UI for that has made it into the 4.7
branch, my guess is not [1].
Theoretically this applies to all folders (not just in IMAP accounts), however
local folders are of course configured by default [2] to just keep headers
loaded and discard bodies as soon as possible.
Cheers,
Kevin
[1] meaning these kind of adjustments can, for now, only be applied through
Akonadiconsole
[2] once there is UI for cache policy managment, that could be changed. use
case for caching contents of a local folder could be if that folder is
actually not all that local (on a network drive or on a removable media for
example).
--
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde/attachments/20110720/612b1cd7/attachment.sig>
-------------- next part --------------
___________________________________________________
This message is from the kde mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.
More information about the kde
mailing list