Review Request 124176: Introduce KPeople contact querying service

Martin Klapetek martin.klapetek at gmail.com
Fri Jun 26 08:33:40 UTC 2015



> On June 26, 2015, 2:05 a.m., Thomas Pfeiffer wrote:
> > Review from a user perspective: If a user has lots of contacts (e.g. in an enterprise setting with an LDAP containing a few thousand coworkers), will the service running in the background take up a lot of memory? And if so, can it be deactivated by those who don't want to use that much memory for that feature?
> > We don't want KPeople to be a burden on anyone, and we have to consider cases with many contacts.
> > If the memory footprint would remain small (let's say no bigger than a few dozen MB) even with a few thousand contacts, it's fine.

Currently the use case is not as much for Plasma desktop as it is for another project, suffice to say that there are no plans for usage of this service on desktops yet. On desktop, however, the service could be made self-killable-when-idle and dbus-started-on-demand. I can't say how big the mem footprint would be for some thousands of contacts. For about 500 it's ~15MB. There's certainly room for optimizations ;)


- Martin


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/124176/#review81761
-----------------------------------------------------------


On June 25, 2015, 3:33 p.m., Martin Klapetek wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/124176/
> -----------------------------------------------------------
> 
> (Updated June 25, 2015, 3:33 p.m.)
> 
> 
> Review request for KDEPIM and Telepathy.
> 
> 
> Repository: kpeople
> 
> 
> Description
> -------
> 
> This is a dbus service that runs in the background and returns contact ids for queried contact details, for example asking for a phone number would return a contact id from which a PersonData class can be constructed, thus making all contact data available for display.
> 
> This is very useful when eg. receiving a phone call, a tp approver starts up showing the incoming call (this needs to be instant) and once it's shown up, it should show a contact name for the number as soon as possible. However loading all the datasources and populating the model can be slow and speed is critical in this case. Therefore it's a dbus service which responds very fast and there's no need to initialize anything as it can be loaded in the background after system starts and it keeps itself always up to date.
> 
> 
> Diffs
> -----
> 
>   autotests/CMakeLists.txt 233e7d9 
>   autotests/servicetest.h PRE-CREATION 
>   autotests/servicetest.cpp PRE-CREATION 
>   src/CMakeLists.txt 59bc915 
>   src/backends/abstractcontact.h ce22cbc 
>   src/backends/abstractcontact.cpp f01236b 
>   src/global.h e1d07ce 
>   src/global.cpp b3595ca 
>   src/service/CMakeLists.txt PRE-CREATION 
>   src/service/main.cpp PRE-CREATION 
>   src/service/org.kde.KPeople.service.in PRE-CREATION 
>   src/service/service.h PRE-CREATION 
>   src/service/service.cpp PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/124176/diff/
> 
> 
> Testing
> -------
> 
> Unit test included; also tested with qdbus.
> 
> 
> Thanks,
> 
> Martin Klapetek
> 
>

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


More information about the KDE-Telepathy mailing list