[Kde-pim] Releasing libkpeople 0.2.0

[David Edmundson]

We are about to release a 0.2.0 release of libkpeople. As you can
imagine after the nepomuk situation we had to rewrite a lot.

I don't think we are completely ABI stable there are a few quite a few
things I want to change, however it is at a good point that I would
like some reviews and feedback.

I've written an overly massive email explainning some of the goals,
designs and current problems.

Goals:
 - To see all information about a person when dealing with a single contact
 - To start actions in different mediums when dealing with a contact
(i.e start an IM chat from kmail, or start an email from IM.. or both
from krunner)
 - Set custom avatar + name alias' to be shown (especially for dealing
with read-only sources)
 - Make it easy to group and switch between contact mediums but never
to completely hide which contact medium is being used.

(New) Architecture:

 - Data is provided at runtime by each source via a plugin system
(basepersonsplugin.h)
 - An SQLite DB stores mappings betweeen client specific contactIds
and a personId. (personmanager_p.h)
 - This works across multiple clients at once via DBus signals. The
database keeps integrity internally.

  - Clients can either:
    - request a model of all people (personsmodel.h)
    - request a single 'person' object using their localID, which has
information from all sources. (persondata.h FIXME rename to just
person?)
    - internally both these use the same object that merges a list of
contacts into a single (metacontact_p.h)

 - DataSources provide KABC::Addresee objects.
    - It's up to the datasource to be async (and fast)
    - Akonadi datasource is in kpeople code  (plugins/akonadi)
      -  datasources must provide a class that lists and monitors
changes in all contacts including adding/removing
(allcontactsdatasource.h)
      -  datasources can provide a class that fetches and monitors
changes for a single contact. (contactdatasource.h)
          (such as showing an avatar + actions in an email view,
without having to load everyone)

Internally data is refcounted, externally to clients it's exposed as
QObjects or Models.

      -  if a plugin doesn't provide the latter, a default
ContactMonitor fetches all the contacts and filters only the relevant
contact (defaultcontactdatasource_p.h)
      - both of these are ref counted internally so fetching the
contact twice, or a model twice does not have any penalty

  - There is another plugin system that provides a list of QActions
that can be started with a person. Start IM chats, send an email, send
a file over IM, etc.  (abstractactionsplugin.h)

  - There are a set of widgets; this is kept into a separate library
for people using this in QML apps.
    - There is a widget/dialog for displaying contact information.
    - We considered re-using the Grantlee system that kaddressbook
currently uses - but ended up going our own way with widgets.
    - This also has a plugin system so prvoviders can interesting
widgets; Such as given a Facebook ID, displaying the last message they
posted, or recent emails. (we had this working with kpeople 0.1 then
lost it at some point)
    - I'm not very happy wtih this part yet. It needs a lot of design work.

 - In order to set "custom" avatars + alias' we will create a new
collection of vcards. This will be the same as any other data source
except that it will be given higher priority when creating the
"metacontact" KABC::Addressee. This collection will be hidden from the
current kaddressbook by specifying a fake mimetype for the vcards.
This will also potentially allow other apps (such as Chokoq) to store
persistent information on a metacontact without having to provide a
datasource.
   This is not entirely implemented yet.

Datasources:
 Complete:
    - akonadi (see plugins/datasources/akonadi)
    - KTp (see ktp-common-internals/kpeople)
 WIP:
    - Skype (in progress. Scrapes and parses skypes internal DBs see
git at git.kde.org:scratch/akulichalexandr/libkpeople)
    - Konversation (mostly just planning ATM)

Current Problems:
 - Groups.
    - KABC::Addresee does not have a field for groups. In Akonadi
terms contacts are from a given contactGroup passing and merging trees
from all the sources will make things much much more complicated for
everyone. My intended plan is for datasources to provide groups as a
vcard role (internally only), and the client can then do what it wants
with them. Right now I abuse the VCard Category property. It turns the
Akonadi data on it's head.. not sure if you would like that.

 - Multiple refreshes
   - Because we have lots of plugins loading asynchronously, they feed
in their own contact data at various times. Each time we get new
information, we update the model which is a lot of dataChanged()
calls. The other option is to wait for everyone to load everything,
but then I'm only as fast as the slowest datasource. Which also sucks.

 - Searching:
    - With Baloo, each app has to implement it's own search store. For
Akonadi this is fine, we create a ContactsSearchJob then get the
relevant IDs. We can then ask KPeople to fetch that item, which will
then in turn that does an akonadi fetch job with a full payload on all
relevant contacts to that person. Scarcely any slower than before.
      However from a krunner POV we want to search all contacts from
all sources - I won't have all this indexed. I think this means every
contact source also needing to write a baloo search plugin. I don't
know what we'll do here.

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