[Kde-pim] Review Request 114117: Port Mail Filter Agent to Akonadi::PreprocessorBase

[Andras Mantia]

> On Nov. 26, 2013, 8:17 a.m., Andras Mantia wrote:
> > agents/mailfilteragent/mailfilteragent.cpp, line 202
> > <http://git.reviewboard.kde.org/r/114117/diff/2/?file=220062#file220062line202>
> >
> >     I also don't understand this removal. This code was there to fetch only what is needed for the mails, thus speeding up the filtering a lot if the filters did not require the full body.
> >     By fetching the full bodies always, in case of online imap you basically turn the online imap account into a disconnected one, as on mail check all bodies will be downloaded.
> 
> Dan Vrátil wrote:
>     Also applies to your comment above: unfortunately with Preprocessor we don't get the items through Monitor (so the monitor could be completely disabled, we just don't have API for that yet), but instead PreprocessorBase gets notified via DBus and fetches the item via ItemFetchJob. This means that MailFilterAgent cannot directly influence fetch of individual items, as it is not aware of it, until processItem() is called. The only solution in this case is to fetch as much as possible.
>     
>     We could work around this by overriding the PreprocessorBasePrivate::beginProcessItem() slot, that is called via D-Bus by Akonadi server, adapt the fetch scope, and call the original implementation. PreprocessorBase does not have constructor for setting subclass of private class, but that could be easily changed. I'll look into it.
> 
> Dan Vrátil wrote:
>     Hmm, I didn't realize that we cannot subclass PreprocessorBasePrivate outside kdepimlibs. The only other option that I could think of is to have virtual ItemFetchScope fetchScopeForCollection( qint64 collection ) method in PreprocessorBase that we call every time before fetching the item in PreprocessorBase. Default implementation would behave like PreprocessorBase::fetchScope(), but MailFilter could reimplement it to return different fetch scope for each collection/resource.
>

Fetching full bodies every time is not acceptable, so we need to find a solution.


- Andras


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/114117/#review44476
-----------------------------------------------------------


On Nov. 25, 2013, 8:33 p.m., Dan Vrátil wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/114117/
> -----------------------------------------------------------
> 
> (Updated Nov. 25, 2013, 8:33 p.m.)
> 
> 
> Review request for KDEPIM.
> 
> 
> Repository: kdepim
> 
> 
> Description
> -------
> 
> When a new item is stored in Akonadi the server first runs it to chain of preprocessors and only after that it notifies regular clients.
> 
> By porting Mail Filter agent to be a preprocessor, filtering happens before the email reaches KMail. As a result, the emails are not piling in Inbox, and then slowly disappearing into their destination folders, but instead they appear in the correct folders right away.
> 
> 
> There was a bug in PreprocessorBase that prevented preprocessor from registering to D-Bus, which is fixed now. To test this patch, you need Akonadi and kdepimlibs from latest master.
> 
> 
> Diffs
> -----
> 
>   CMakeLists.txt 5fcce93 
>   agents/mailfilteragent/filtermanager.h b95fc15 
>   agents/mailfilteragent/filtermanager.cpp a9b76f1 
>   agents/mailfilteragent/mailfilteragent.h c8ca7b4 
>   agents/mailfilteragent/mailfilteragent.cpp 5168cf0 
> 
> Diff: http://git.reviewboard.kde.org/r/114117/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Dan Vrátil
> 
>

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