Review Request 114349: Use one Akonadi::EntityTreeModel instead of Akonadi::Monitors in AkonadiDataSource

[David Edmundson]

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



src/plugins/akonadi/akonadidatasource.cpp
<http://git.reviewboard.kde.org/r/114349/#comment32368>

    This defeats the entire point of this API.
    
    The API was designed so that if we only want to fetch data for one contact (which is a valid use case a lot - like in the text-ui or konversation or kmail etc.) we don't load /every/ contact from every data source nor do we want to monitor every contact.
    
    This was all cleverly designed to minimise traffic as much as possible and this change would ruin all of that.
    
    (also this class just reproduces DefaultContactMonitor)
    
    I guess it's my fault for not documenting yet.


On the ETM model change, I struggle to believe that Akonadi fetching the data then building a model only for us to then scrape the model for the data is going to be more efficient than us just loading the data.

- David Edmundson


On Dec. 8, 2013, 2:48 a.m., Dan Vrátil wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/114349/
> -----------------------------------------------------------
> 
> (Updated Dec. 8, 2013, 2:48 a.m.)
> 
> 
> Review request for Telepathy.
> 
> 
> Repository: libkpeople
> 
> 
> Description
> -------
> 
> Use a single ETM instead of manually fetching all contacts and then installing a new Akonadi Monitor for each single AkonadiContact.
> 
> ETM (with EntityMimeTypeFilterModel on top) will do the CollectionFetchJobs and ItemFetchJobs and data handling for us, which only leaves us with handling of changes, which we do in slots for QAbstractItemModel's rowsInserted(), rowsRemoved() and dataChanged() signals. This is much better than having many Akonadi monitors, because for each change notification that Akonadi server generates, it has to iterate over all registered monitors and compare the notification against each monitor's filter. With lots of monitors, this can impact performance of the server. Although the AkonadiContacts with their Akonadi monitors are created on demand (so there's none at the beginning), they are not removed (probably cached somewhere in PersonsModel), so the number of active Akonadi monitors tends to grow - for instance going through all contacts in PersonViewer will leave you with one monitor for each contact fed from Akonadi.
> 
> From Akonadi POV, having one properly configured monitor (hidden in ETM) and working with data via ETM is a better approach.
> 
> 
> Diffs
> -----
> 
>   CMakeLists.txt 889e96d 
>   src/plugins/akonadi/akonadidatasource.h b09edf8 
>   src/plugins/akonadi/akonadidatasource.cpp 193de78 
> 
> Diff: http://git.reviewboard.kde.org/r/114349/diff/
> 
> 
> Testing
> -------
> 
> Going through all contacts in PersonViewer includes all contacts from Akonadi, and the application uses only one Akonadi Monitor all the time.
> 
> 
> Thanks,
> 
> Dan Vrátil
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-telepathy/attachments/20131208/f286d660/attachment.html>