Review Request 124176: Introduce KPeople contact querying service

[Martin Klapetek]

> 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.
> 
> Martin Klapetek wrote:
>     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 ;)
> 
> Alexander Potashev wrote:
>     I'm writing this on Android, and I have an app that works as an offline GPS navigation and a phone book (it's called 2GIS). It includes contact info for around 300k companies in Moscow, 130k in St Petersburg and some more in other cities in Russia and a few other countries. I estimate the total number of companies to be around 2M. Let's say there's one phone number per company.
>     
>     Now, any of these companies can possibly call me and I want to know which one it was. Ok, I never received calls from commercial companies in Russia from outside of Moscow and St Petersburg, but we can't disable a workflow when the user is called from numerous companies all over the world. So to implement the same as 2GIS does with the help of KPeople we need to load all these 2M phone numbers into KPeople. A resident RAM storage is clearly unacceptable here because it would take at least some hundreds of megabytes.

KPeople is also meant to power the phonebook. Now if you do have all those phone numbers present on the phone _and_ in the actual phonebook, then I think you have other problems than this service. Just opening the address book powered by kpeople would load all those 2M contacts into memory and would probably take ages just to show up. So for your use case, KPeople is probably not what you're looking for anyway (and it's not meant to be).


- 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/9737b877/attachment.html>