Contacts Plugin

[Andy Holmes]

Probably the most flexible is to keep them cached, in vCard or even
flat JSON since that's how it's received, in a directory with
permissions restricted to the local user. It's not unlikely each phone
might have different contacts (eg, work phone, personal phone) so
should have their own file/directory and leaving the data in an easily
parsable format means applications could write contact providers as
needed.

On Tue, Jan 16, 2018 at 12:12 PM, Aleix Pol <aleixpol at kde.org> wrote:
> On Tue, Jan 16, 2018 at 8:56 PM, Nicolas Fella <nicolas.fella at gmx.de> wrote:
>> On Dienstag, 16. Januar 2018 01:43:07 CET Aleix Pol wrote:
>>> On Sat, Jan 6, 2018 at 3:03 AM, Simon Redman <simon at ergotech.com> wrote:
>>> > I have just put up a contacts plugin for review
>>> >
>>> > In its current form, it is extremely primitive. Probably too basic to be
>>> > usable. The KDE-side has a DBus slot which takes no arguments but sends
>>> > a request to the Android side for its entire contacts book. The contacts
>>> > book comes back, and is then sent back on DBus as a massive list of
>>> > strings, one name, followed by one number.
>>> >
>>> > I know that there are projects/people other than me interested in this
>>> > functionality, so I am looking for input from those people for what they
>>> > would like to see in terms of a better DBus API
>>> >
>>> > Also code-review feedback, because I don't have much real-world
>>> > experience :(
>>>
>>> Hi Simon,
>>> It's definitely interesting, something we have discussed in the past even.
>>> How do you expect to present these contacts?
>>>
>>> Aleix
>> Hi,
>>
>> thanks for your work on this!
>>
>> Before implementing things we should think about the use-cases we want to
>> serve. I was thinking about a import from device function in KAddressbook.
>> Another often demanded feature is writing SMS from the desktop. We also should
>> care about privacy here (it got selected as one of our primary goals).
> +1
>
>> Obviously the user has to consent by giving the contacts permission, but she/
>> he might want to restrict access to certain applications, so we might need to
>> restrict who can read from the DBus interface.
>
> There's no much of a security model around dbus, so it's probably not doable.
>
> Another way to implement it would be to keep a synchronized set of
> vcards on the system.
>
> Aleix