[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-pim
Subject:    Re: [Kde-pim] Question about notifications+IMAP
From:       Szymon Tomasz Stefanek <pragma () kvirc ! net>
Date:       2009-07-29 12:47:54
Message-ID: 200907291447.55238.pragma () kvirc ! net
[Download RAW message or body]

On Wednesday 29 July 2009, Volker Krause wrote:

> [...]
> There are even more cases where the hidden items could cause problems:
> [...]

Yep, the more I think of it the more complex failure scenarios come to my
mind. Well... one could attempt to fix them all but...

> [...]
> So, we not only need to record the session id, but also all other change
> notifications that would normally happen while the item is in the
> preprocssing chain.

Hm, replaying a sequence of changes looks a bit weird to me.
Think of two move notifications (ok, this is rare, but can happen).

When the first replayed move notification is triggered the
second move has already happened. This means that the
target collection of the first notification does not match
the real collection that the item is in.

Murphy's law states that weird things will happen sooner or later...

Anyway, this leads me somewhat out of the track, let's go back.

> [...]
> Another idea might be to not return from an APPEND command unless the
> preprocessing has been completed, effectively making the preprocessing
> synchronous. Not sure what other side-effects that might have, it will
> definitely fail for retrieving more data from the resource though (the IMAP
> load on demand attachments case).

We should also assume that the preprocessing of an item can take a long time.

Think of the "check mail" button in a mail client that has many accounts.
Multiple resrouces will concurrently push a lot of items to the preprocessor
queue.... which is a queue and thus a bottleneck (especially if spamassassin
is present in one of the filters)...


Ok. Why not a yet different approach.


We hide the items at UI application level instead of the akonadi server.

In the end what we want to achieve is that the user does not see the item
randomly changing while it's being preprocessed. However the item IS actually
preprocessed and it may even undergo dramatic changes in the meantime: what if
the spamfilter decides to delete the message?

So we actually emit all the standard notifications for the hidden items and
thus wipe out all of the problems above. Instead we explicitly state that
the hidden flag is meant to be handled at UI level: a hidden item shouldn't
be displayed to the user (unless in "debug" mode).

Unhiding the item triggers a standard itemChanged() notification:
the UI notices that the item is no longer hidden and displays it.

This could be implemented at some API level in kdepimlibs. Still
have to find out exactly where but the item models are possibly
the first candidates to evaluate.

-- 

Szymon Tomasz Stefanek

------------------------------------------------------------------------------
-
- Solitary trees, if they grow at all, grow strong.
-
------------------------------------------------------------------------------

_______________________________________________
KDE PIM mailing list kde-pim@kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/
[prev in list] [next in list] [prev in thread] [next in thread]