Metacontacts/KPeople status

[David Edmundson]

I've had an idea.
It's possibly controversial.

The current state:
 - KPeople relies on ktp-common-internals because we have a lot of useful
code we don't want to reproduce.
global-contact-manager, KTp::Contact itself with logic for working out
shared capabilities and gabble workarounds, and listing actions etc. We are
now able to dynamically list all actions including stream/dbus tubes we
want to be able to do that in all places.


Apol (correctly IMHO) thinks this is a problem as kpeople should be
entering as a framework without a dependency on ktp-common-internals. This
is probably a requirement if we want to be used in PIM.
Long term I want the switching between kpeople and contact-list-model to be
done behind the scenes, which means k-c-i has to depend on kpeople. This
would be a circular dependency.

Option 1:
 - we duplicate a tonne of code (bad)

Option 2:
 - kpeople has a plugin infrastructure.
we only need ktp-common-internals at runtime.

So what if it went like this:

kpeople builds a model. Then it loads a set of plugins (passed as a
stringlist to the constructor) this can set a QIdentityProxyModel (like we
use at the moment)
The telepathy part of kpeople can then reside in our repository as a
kpeople plugin

This would also allow for us to add actions easily, and would allow other
people to extend kpeople too with any actions or UI components or anything.

It's not a lot of work mostly moving some things, and a design that I think
is pretty clean, simple and extensible.

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