API improvement suggestions

[David Edmundson]

On Mon, Aug 24, 2015 at 8:21 PM, Ivan Čukić <ivan.cukic at kde.org> wrote:

> Hi,
>
> > There's a QIdentityProxyModel model in KTp that effectively
>
> While that seems to be sufficient, it is KTp-specific.
>
> It would be nice if I was also able to show if there are new e-mails
> for a specific contact.
>
(and the fact I'd like to have the same thing
> from two different places that are supposed to be supported by KPeople
> tells me it should be supported by KPeople :) )
>
> It would be great if clients did not need to know of KTp nor Akonadi
> do be able to do basic things. And I see this as a basic thing.
> Naturally, if you don't, I'll just use KTp directly.
>

I don't disagree. It's a matter of tradeoffs.

This current model has:
 - unread count
 - the last message content (and which way it went)
 - whether a chat window is open

if we try putting all that in kpeople,we either get a lot of very app
specific things or we have to cut it down to the essentials.
If we do the latter we get code duplication or loss of functionality in
other stuff.

We'd also need a way to turn these things on/off in kpeople as a
prerequisite, channel traffic has a reasnoble overhead here and scanning
emails would have an even bigger one. We used to have something to do that;
but I thing that got lost in the rewrite after me? Not sure.

If the PIM side was closer to being done I'd be more inclined to lean
towards your thinking, but as it is, I'm not even sure the Akonadi part is
building let alone the rest of the essentials in PIM.

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